sql-server - pero - integration services sql server 2008

¿Qué credenciales de usuario utiliza el catálogo de Integration Services para ejecutar paquetes? (3)

Tenemos un paquete SSIS que lee archivos de texto de un directorio de red compartido. Cuando ejecuto este paquete en SSDT funciona bien. Sin embargo, cuando implementamos el proyecto en el Integration Services Catalog e intentamos ejecutar el mismo paquete desde allí, aparece un error que indica que se denegó el acceso al directorio.

Siempre he tenido la impresión de que cuando inicio sesión en la base de datos y ejecuto un paquete SSIS del Catálogo de Integration Services que utiliza MIS credenciales de usuario y por lo tanto tendría acceso al directorio en cuestión ya que mi perfil de usuario tiene acceso a él. .

¿No es este el caso? ¿SQL Server utiliza un usuario diferente para ejecutar paquetes desde el catálogo de IS? ¿Hay una opción para run as another user ? Cualquier contribucion sera apreciada.

Ejecuciones de paquetes:

Herramientas de datos de SQL Server:

Las credenciales de usuario bajo las cuales se utilizan las SQL Server Data Tools (SSDT) se utilizarán para ejecutar los paquetes que se ejecutan dentro de SSDT.

En Windows Inicio / Todos los programas / Microsoft SQL Server 2012, si hace clic en Herramientas de datos de SQL Server, se ejecutará bajo sus credenciales. Para ejecutar una cuenta de usuario diferente, puede presionar Ctrl + Mayús para seleccionar Run as different user opción de Run as different user .

Servicios de catálogo de integración:

Cuando hace clic con el botón derecho en un paquete bajo Integration Services Catalog / SSISDB / <Folder name> / Projects / <Project name> / Packages / <Package name> y seleccione Execute... para ejecutar un paquete. El paquete se ejecutará bajo las credenciales utilizadas para conectarse a SQL Server Management Studio.

Tenga en cuenta que si intenta ejecutar un paquete utilizando la autenticación de SQL Server, recibirá el siguiente mensaje de error:

La operación no puede iniciarse con una cuenta que use la autenticación de SQL Server. Inicie la operación con una cuenta que use la autenticación de Windows.

Después de presionar Execute... , SQL Server ISServerExec.exe un proceso ISServerExec.exe , que inicia un proceso de Console Window Host :

ISServerExec.exe es un programa que ejecuta paquetes en el Catálogo SSIS. En este caso, se inicia bajo el mismo usuario que ejecuta un paquete SSIS desde SQL Server Management Studio.

Trabajo del Agente SQL Server Sin Proxy:

Cuando ejecuta un paquete SSIS desde un trabajo del Agente SQL Server , el paso del trabajo se ejecuta de forma predeterminada en la SQL Server Agent Service Account . Puede encontrar el servicio del Agente SQL Server asociado a la cuenta de usuario navegando a Windows Start / Administrative Tools / Services , busque el servicio Agente SQL Server (nombre de Your Instance Name ) y busque la cuenta de usuario que se encuentra en Log On As

Trabajo del Agente SQL Server con Proxy:

También puede ejecutar un trabajo del Agente SQL Server con diferentes credenciales creando una cuenta proxy. Cuando los pasos de trabajo se ejecutan bajo una cuenta de proxy, el paquete en el paso de trabajo se ejecutará bajo la credencial especificada en la cuenta de proxy.

A continuación, la respuesta de SO proporciona instrucciones paso a paso para crear una cuenta de proxy para ejecutar trabajos del Agente SQL Server.

¿Cómo creo un paso en mi trabajo del Agente SQL Server que ejecutará mi paquete SSIS?

Cómo verificar:

Paquete de muestra SSIS 2012:

Esto es lo que hice para verificar las declaraciones anteriores con respecto a las cuentas de usuario utilizadas para las ejecuciones de paquetes.

Abra SQL Server Data Tools y cree un paquete SSIS 2012 llamado SO_15289442.dtsx .
Cree una variable llamada ExecutionUser de tipo de datos String . Asigne la expresión @[System::UserName] a la variable. UserName es una variable del sistema que proporciona la información del usuario que ejecuta el paquete.
Arrastre y suelte Enviar tarea de correo en la pestaña Flujo de datos .
Cree una conexión SMTP y asígnela a SmtpConnection en el editor de tareas Enviar correo: página de correo.
Especifique las direcciones de correo electrónico From y To .
Cambie el MessageSourceType a Variable .
Establezca MessageSource en User::ExecutionUser .
Haga clic con el botón derecho en el paquete y seleccione Implementar para implementar el proyecto en el Catálogo de servicios de integración disponible en un servidor de su elección.

Paquete de ejecuciones

Ejecute el paquete dentro de SSDT.
Abra SSDT usando la opción Ejecutar como usuario diferente. Proporcione una credencial diferente a la suya y vuelva a ejecutar el paquete.
Ejecute el paquete desde el catálogo de servicios de integración.
Cree un trabajo del Agente SQL Server para ejecutar el paquete utilizando la cuenta de servicio del Agente SQL Server.
Cree un trabajo del Agente SQL Server para ejecutar el paquete usando una cuenta proxy.

Por cada ejecución mencionada anteriormente, recibirá un correo electrónico con la cuenta de usuario que se utilizó para ejecutar el paquete.

Tu problema:

En su caso, el paquete se ejecutará bajo su cuenta ( asumiendo que está usando sus credenciales para acceder a SSISDB ) si hace clic con el botón derecho y selecciona Ejecutar desde el Catálogo de Servicios de Integración. Asegúrese de que la carpeta tenga acceso a la ruta de la red.

Si está ejecutando su paquete desde SQL Server Agent Job, la cuenta de proxy es la opción de run as another user opción de run as another user que está viendo.

Este es un hilo antiguo, pero me imagino que el problema que está experimentando es en realidad con la ruta del archivo. ¿Está utilizando un nombre UNC o una letra de unidad. Es decir, ¿es su ruta de archivo algo así como "Z: / ruta / a / archivo.csv" o "/ server / share / ruta / a / archivo.csv"?

Si es una letra de unidad, funcionará bien desde su máquina local, ya que tiene esa unidad asignada, pero fallará en el servidor ya que la letra de la unidad no está asignada.

Parece que no tiene Kerberos configurado en su servidor SQL (problema de doble salto).

Aquí está el problema registrado con MS que se ha solucionado ahora. https://connect.microsoft.com/SQLServer/feedback/details/767088/with-the-new-ability-to-execute-ssis-packages-from-tsql-kerberos-delegation-should-be-supported

Aquí hay una excelente publicación en el blog sobre los detalles de esto: http://www.sqlscientist.com/2014/01/setup-kerberos-authentication-for-sql.html

Una vez que esté configurado, debería poder iniciar el trabajo de forma remota utilizando un procedimiento almacenado o SSMS en su máquina local. Pasará sus credenciales si está configurada correctamente, por supuesto, debe asegurarse de tener los permisos adecuados para acceder al recurso de red.