El paquete SSIS no se ejecuta cuando se llama desde un paso de trabajo de Agente SQL Server

  • Artículo

Este artículo le ayuda a resolver el problema que se produce al llamar a un paquete SSIS desde un paso de trabajo de Agente SQL Server.

Versión del producto original: SQL Server
Número de KB original: 918760

Síntomas

Al llamar a un paquete de Microsoft SQL Server Integration Services (SSIS) desde un paso de trabajo de Agente SQL Server, el paquete SSIS no se ejecuta. Sin embargo, si no modifica el paquete SSIS, se ejecutará correctamente fuera de Agente SQL Server.

Solución

Para resolver el problema, use uno de los siguientes métodos. El método más adecuado depende del entorno y de la razón por la que se produjo un error en el paquete. Los motivos por los que el paquete puede haber producido un error son los siguientes:

  • La cuenta de usuario que se usa para ejecutar el paquete en Agente SQL Server difiere del autor del paquete original.
  • La cuenta de usuario no tiene los permisos necesarios para establecer conexiones o acceder a recursos fuera del paquete SSIS.

Es posible que el paquete no se ejecute en los siguientes escenarios:

  • El usuario actual no puede descifrar los secretos del paquete. Este escenario puede producirse si la cuenta actual o la cuenta de ejecución difiere del autor del paquete original y la configuración de la propiedad ProtectionLevel del paquete no permite que el usuario actual descifre secretos en el paquete.
  • Se produce un error en una conexión SQL Server que usa la seguridad integrada porque el usuario actual no tiene los permisos necesarios.
  • Se produce un error en el acceso a archivos porque el usuario actual no tiene los permisos necesarios para escribir en el recurso compartido de archivos al que accede el administrador de conexiones. Por ejemplo, este escenario puede producirse con proveedores de registro de texto que no usan un inicio de sesión y una contraseña. Este escenario también puede producirse con cualquier tarea que dependa del administrador de conexiones de archivos, como una tarea del sistema de archivos SSIS.
  • Una configuración de paquete SSIS basada en el Registro usa las claves del HKEY_CURRENT_USER Registro. Las HKEY_CURRENT_USER claves del Registro son específicas del usuario.
  • Una tarea o un administrador de conexiones requiere que la cuenta de usuario actual tenga permisos correctos.

Para resolver el problema, use los métodos siguientes:

  • Método 1: use una cuenta de proxy de Agente SQL Server. Cree una cuenta de proxy de Agente SQL Server. Esta cuenta de proxy debe usar una credencial que permita Agente SQL Server ejecutar el trabajo como la cuenta que creó el paquete o como una cuenta que tenga los permisos necesarios.

    Este método funciona para descifrar secretos y satisface los requisitos de clave por parte del usuario. Sin embargo, este método puede tener un éxito limitado porque las claves de usuario del paquete SSIS implican al usuario actual y al equipo actual. Por lo tanto, si mueve el paquete a otro equipo, este método todavía puede producir un error, incluso si el paso de trabajo usa la cuenta de proxy correcta.

  • Método 2: establezca la propiedad Paquete ProtectionLevel SSIS en ServerStorage. Cambie la propiedad SSIS Package ProtectionLevel a ServerStorage. Esta configuración almacena el paquete en una base de datos SQL Server y permite el control de acceso a través de SQL Server roles de base de datos.

  • Método 3: establezca la propiedad EncryptSensitiveWithPasswordPaquete ProtectionLevel SSIS en . Cambie la propiedad Paquete ProtectionLevel SSIS a EncryptSensitiveWithPassword. Esta configuración usa una contraseña para el cifrado. A continuación, puede modificar la línea de comandos Agente SQL Server paso de trabajo para incluir esta contraseña.

  • Método 4: Use archivos de configuración del paquete SSIS. Use los archivos de configuración del paquete SSIS para almacenar información confidencial y, a continuación, almacene estos archivos de configuración en una carpeta protegida. A continuación, puede cambiar la ProtectionLevel propiedad a para DontSaveSensitive que el paquete no esté cifrado y no intente guardar secretos en el paquete. Al ejecutar el paquete SSIS, la información necesaria se carga desde el archivo de configuración. Asegúrese de que los archivos de configuración estén protegidos adecuadamente si contienen información confidencial.

  • Método 5: Crear una plantilla de paquete. Para una resolución a largo plazo, cree una plantilla de paquete que use un nivel de protección que difiere de la configuración predeterminada. Este problema no se producirá en paquetes futuros.

Pasos para reproducir el problema

  1. Inicie sesión como un usuario que no forme parte del grupo SQLServerSQLAgentUser. Por ejemplo, puede crear un usuario local.
  2. Cree un paquete SSIS y agregue una tarea ExecuteSQL. Use un administrador de conexiones OLE DB en el archivo msdb local mediante la cadena siguiente: 'Windows Authentication' -SQLSourceType: "Direct Input" -SQLStatement: "sp_who".
  3. Ejecute el paquete para asegurarse de que se ejecuta correctamente.
  4. La propiedad ProtectionLevel se configura como EncryptSensitiveWithPassword.
  5. Cree un trabajo Agente SQL Server y un paso de trabajo. En la lista Ejecutar como, haga clic en Agente SQL Server Servicio para ejecutar el paso de trabajo. El texto del Agente SQL Server Historial de trabajos muestra información similar a la siguiente:

Descifrar secretos de paquete

La configuración predeterminada para la propiedad del paquete ProtectionLevel SSIS es EncryptSensitiveWithUserKey. Cuando se guarda el paquete, SSIS cifra solo las partes del paquete que contienen propiedades marcadas sensitivecomo , como contraseñas, nombres de usuario y cadenas de conexión. Por lo tanto, cuando se vuelve a cargar el paquete, el usuario actual debe cumplir los requisitos de cifrado para que se descifren las sensitive propiedades. Sin embargo, el usuario actual no tiene que cumplir los requisitos de cifrado para cargar el paquete. Al ejecutar el paquete a través de un paso de trabajo Agente SQL Server, la cuenta predeterminada es la cuenta de servicio de Agente SQL Server. Es muy probable que esta cuenta predeterminada sea un usuario diferente al autor del paquete. Por lo tanto, el paso de trabajo Agente SQL Server puede cargarse e iniciarse para ejecutar el paso de trabajo, pero se produce un error en el paquete porque no puede completar una conexión. Por ejemplo, el paquete no puede completar una conexión OLE DB o una conexión FTP. Se produce un error en el paquete porque no puede descifrar las credenciales que debe tener para conectarse.

Importante

Considere el proceso de desarrollo y el entorno para determinar qué cuentas se necesitan y se usan en cada equipo. El valor EncryptSensitiveWithUserKey de la ProtectionLevel propiedad es una configuración eficaz. Esta configuración no se debe descontar porque provoca complicaciones de implementación al principio. Puede cifrar los paquetes cuando haya iniciado sesión en la cuenta adecuada. También puede usar la utilidad del símbolo del sistema de SSIS Dtutil.exe para cambiar los niveles de protección mediante un archivo .cmd y el subsistema de comandos Agente SQL Server. Por ejemplo, siga estos pasos. Dado que puede usar la utilidad Dtutil.exe en archivos y bucles por lotes, puede seguir estos pasos para varios paquetes al mismo tiempo.

  1. Modifique el paquete que desea cifrar mediante una contraseña.

  2. Use la utilidad Dtutil.exe a través de un paso de trabajo Agente SQL Server sistema operativo (cmd Exec) para cambiar la ProtectionLevel propiedad a EncryptSensitiveWithUserKey. Este proceso implica descifrar el paquete mediante la contraseña y, a continuación, volver a cifrar el paquete. La clave de usuario que se usa para cifrar el paquete es la configuración del paso de trabajo Agente SQL Server en la lista Ejecutar como.

    Nota:

    Dado que la clave incluye el nombre de usuario y el nombre del equipo, el efecto de mover los paquetes a otro equipo puede ser limitado.

Asegúrese de que tiene información detallada sobre el error del paquete SSIS.

En lugar de confiar en los detalles limitados del Agente SQL Server historial de trabajos, puede usar el registro de SSIS para asegurarse de que tiene información de error sobre el error del paquete SSIS. También puede ejecutar el paquete mediante el comando exec subsystem en lugar del comando del subsistema SSIS.

Acerca del registro de SSIS

Los proveedores de registro y registro de SSIS permiten capturar detalles sobre la ejecución y los errores del paquete. De forma predeterminada, el paquete no registra información. Debe configurar el paquete para registrar información. Al configurar el paquete para registrar información, se muestra información detallada similar a la siguiente. En este caso, sabrá que se trata de un problema de permisos:

OnError,DOMAINNAME,DOMAINNAME\USERNAME,FTP Task,{C73DE41C-D0A6-450A-BB94-DF6D913797A1},{2F0AF5AF-2FFD-4928-88EE-1B58EB431D74},4/28/2006 1:51:59 PM,4/28/2006 1:51:59 PM,-1073573489,0x,Unable to connect to FTP server using "FTP Connection Manager".

OnError,DOMAINNAME,DOMAINNAME\USERNAME,Execute SQL Task,{C6C7286D-57D4-4490-B12D-AC9867AE5762},{F5761A49-F2F9-4575-9E2B-B3D381D6E1F3},4/28/2006 4:07:00 PM,4/28/2006 4:07:00 PM,-1073573396,0x,Failed to acquire connection "user01.msdb". Connection may not be configured correctly or you may not have the right permissions on this connection.

Información sobre el comando del subsistema exec y la información de salida

Mediante el enfoque de comandos del subsistema exec, se agregan modificadores detallados de registro de consola a la línea de comandos de SSIS para llamar al archivo ejecutable de la línea de comandos de SSIS Dtexec.exe. Además, se usa la característica De trabajo avanzado del archivo de salida. También puede usar la opción Incluir salida de paso en el historial para redirigir la información de registro a un archivo o al Agente SQL Server historial de trabajos.

A continuación se muestra un ejemplo de una línea de comandos:

 dtexec.exe /FILE "C:\_work\SSISPackages\ProtectionLevelTest\ProtectionLevelTest\AgentTesting.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING V /CONSOLELOG NCOSGXMT

El registro de consola devuelve detalles similares a los siguientes:

Error: 2006-04-27 18:13:34.76 Code: 0xC0202009 Source: AgentTesting Connection manager "(local).msdb" Description: An OLE DB error has occurred. Error code: 0x80040E4D. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E4D Description: "Login failed for user 'DOMAINNAME\username'.". End Error

Error: 2006-04-28 13:51:59.19 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS:Property" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error

Log: Name: OnError Computer: COMPUTERNAME Operator: DOMAINNAME\username Source Name: Execute SQL Task Source GUID: {C6C7286D-57D4-4490-B12D-AC9867AE5762} Execution GUID: {7AFE3D9E-5F73-42F0-86FE-5EFE264119C8} Message: Failed to acquire connection "(local).msdb". Connection may not be configured correctly or you may not have the right permissions on this connection. Start Time: 2006-04-27 18:13:34 End Time: 2006-04-27 18:13:34 End Log

Referencias

Desafortunadamente, los usuarios no son conscientes de que la configuración predeterminada del paso de trabajo del agente los coloca en este estado. Para obtener más información sobre los servidores proxy de Agente SQL Server y SSIS, consulte los temas siguientes en los Libros en pantalla de SQL Server 2005:

  • Programación de la ejecución de paquetes en Agente SQL Server
  • Creación de servidores proxy de Agente SQL Server