Dela via

SSIS-paketet körs inte när det anropas från ett steg i SQL Server Agent-jobbet

  • Artikel

Den här artikeln hjälper dig att lösa problemet som uppstår när du anropar ett SSIS-paket från ett SQL Server Agent-jobbsteg.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 918760

Symptom

När du anropar ett SSIS-paket (Microsoft SQL Server Integration Services) från ett SQL Server Agent-jobbsteg körs inte SSIS-paketet. Men om du inte ändrar SSIS-paketet körs det utan problem utanför SQL Server-agenten.

Åtgärd

Använd en av följande metoder för att lösa problemet. Den lämpligaste metoden beror på miljön och orsaken till att paketet misslyckades. Orsaker till att paketet kan ha misslyckats är följande:

  • Det användarkonto som används för att köra paketet under SQL Server Agent skiljer sig från den ursprungliga paketförfattaren.
  • Användarkontot har inte de behörigheter som krävs för att upprätta anslutningar eller komma åt resurser utanför SSIS-paketet.

Paketet kanske inte körs i följande scenarier:

  • Den aktuella användaren kan inte dekryptera hemligheter från paketet. Det här scenariot kan inträffa om det aktuella kontot eller körningskontot skiljer sig från den ursprungliga paketförfattaren och paketets egenskapsinställning ProtectionLevel inte tillåter att den aktuella användaren dekrypterar hemligheter i paketet.
  • En SQL Server-anslutning som använder integrerad säkerhet misslyckas eftersom den aktuella användaren inte har de behörigheter som krävs.
  • Filåtkomsten misslyckas eftersom den aktuella användaren inte har de behörigheter som krävs för att skriva till den filresurs som anslutningshanteraren har åtkomst till. Det här scenariot kan till exempel inträffa med textloggprovidrar som inte använder en inloggning och ett lösenord. Det här scenariot kan också inträffa med alla aktiviteter som är beroende av filanslutningshanteraren, till exempel en SSIS-filsystemaktivitet.
  • En registerbaserad SSIS-paketkonfiguration använder registernycklarna HKEY_CURRENT_USER . Registernycklarna HKEY_CURRENT_USER är användarspecifika.
  • En uppgift eller en anslutningshanterare kräver att det aktuella användarkontot har rätt behörigheter.

Lös problemet genom att använda följande metoder:

  • Metod 1: Använd ett SQL Server Agent-proxykonto. Skapa ett SQL Server Agent-proxykonto. Det här proxykontot måste använda en autentiseringsuppgift som gör att SQL Server Agent kan köra jobbet som det konto som skapade paketet eller som ett konto som har nödvändiga behörigheter.

    Den här metoden fungerar för att dekryptera hemligheter och uppfyller de viktigaste kraven för användaren. Den här metoden kan dock ha begränsad framgång eftersom användarnycklarna för SSIS-paketet omfattar den aktuella användaren och den aktuella datorn. Om du flyttar paketet till en annan dator kan den här metoden därför fortfarande misslyckas, även om jobbsteget använder rätt proxykonto.

  • Metod 2: Ange egenskapen SSIS Package ProtectionLevel till ServerStorage. Ändra egenskapen SSIS Package ProtectionLevel till ServerStorage. Den här inställningen lagrar paketet i en SQL Server-databas och ger åtkomstkontroll via SQL Server-databasroller.

  • Metod 3: Ange egenskapen SSIS Package ProtectionLevel till EncryptSensitiveWithPassword. Ändra egenskapen SSIS-paket ProtectionLevel till EncryptSensitiveWithPassword. Den här inställningen använder ett lösenord för kryptering. Du kan sedan ändra kommandoraden för SQL Server Agent-jobbsteget så att det innehåller det här lösenordet.

  • Metod 4: Använd SSIS-paketkonfigurationsfiler. Använd SSIS-paketkonfigurationsfiler för att lagra känslig information och lagra sedan dessa konfigurationsfiler i en skyddad mapp. Du kan sedan ändra ProtectionLevel egenskapen till DontSaveSensitive så att paketet inte krypteras och inte försöker spara hemligheter i paketet. När du kör SSIS-paketet läses nödvändig information in från konfigurationsfilen. Kontrollera att konfigurationsfilerna är tillräckligt skyddade om de innehåller känslig information.

  • Metod 5: Skapa en paketmall. För en långsiktig lösning skapar du en paketmall som använder en skyddsnivå som skiljer sig från standardinställningen. Det här problemet uppstår inte i framtida paket.

Steg för att återskapa problemet

  1. Logga in som en användare som inte ingår i gruppen SQLServerSQLAgentUser. Du kan till exempel skapa en lokal användare.
  2. Skapa ett SSIS-paket och lägg sedan till en ExecuteSQL-uppgift. Använd en OLE DB-anslutningshanterare till den lokala msdb-filen med hjälp av följande sträng: 'Windows Authentication' -SQLSourceType: "Direct Input" -SQLStatement: "sp_who".
  3. Kör paketet för att se till att det körs korrekt.
  4. Egenskapen ProtectionLevel anges till EncryptSensitiveWithPassword.
  5. Skapa ett SQL Server Agent-jobb och ett jobbsteg. I listan Kör som klickar du på SQL Server Agent Service för att köra jobbsteget. Texten i SQL Server Agent-jobbhistoriken visar information som liknar följande:

Dekryptera pakethemligheter

Standardinställningen för SSIS-paketegenskapen ProtectionLevel är EncryptSensitiveWithUserKey. När paketet sparas krypterar SSIS endast de delar av paketet som innehåller egenskaper som är markerade sensitive, till exempel lösenord, användarnamn och anslutningssträng. När paketet läses in igen måste därför den aktuella användaren uppfylla krypteringskraven för sensitive att egenskaperna ska dekrypteras. Den aktuella användaren behöver dock inte uppfylla krypteringskraven för att läsa in paketet. När du kör paketet via ett SQL Server Agent-jobbsteg är standardkontot SQL Server Agent Service-kontot. Det här standardkontot är troligen en annan användare än paketförfattaren. Därför kan SQL Server Agent-jobbsteget läsa in och börja köra jobbsteget, men paketet misslyckas eftersom det inte kan slutföra en anslutning. Paketet kan till exempel inte slutföra en OLE DB-anslutning eller en FTP-anslutning. Paketet misslyckas eftersom det inte kan dekryptera de autentiseringsuppgifter som måste anslutas.

Viktigt!

Överväg utvecklingsprocessen och miljön för att avgöra vilka konton som behövs och används på varje dator. Inställningen EncryptSensitiveWithUserKey för ProtectionLevel egenskapen är en kraftfull inställning. Den här inställningen bör inte rabatteras eftersom den orsakar distributionskomplikationer först. Du kan kryptera paketen när du är inloggad på rätt konto. Du kan också använda kommandotolken Dtutil.exe SSIS för att ändra skyddsnivåer med hjälp av en .cmd-fil och SQL Server Agent-kommandoundersystemet. Följ till exempel dessa steg. Eftersom du kan använda verktyget Dtutil.exe i batchfiler och -loopar kan du följa dessa steg för flera paket samtidigt.

  1. Ändra det paket som du vill kryptera med hjälp av ett lösenord.

  2. Använd Dtutil.exe-verktyget via ett SQL Server Agent-jobbsteg för operativsystem (cmd Exec) för att ändra ProtectionLevel egenskapen till EncryptSensitiveWithUserKey. Den här processen innebär att dekryptera paketet med hjälp av lösenordet och sedan kryptera paketet igen. Den användarnyckel som används för att kryptera paketet är inställningen för SQL Server Agent-jobbsteget i listan Kör som .

    Kommentar

    Eftersom nyckeln innehåller användarnamnet och datornamnet kan effekten av att flytta paketen till en annan dator begränsas.

Kontrollera att du har detaljerad felinformation om SSIS-paketfelet

I stället för att förlita dig på den begränsade informationen i SQL Server Agent-jobbhistoriken kan du använda SSIS-loggning för att se till att du har felinformation om SSIS-paketfelet. Du kan också köra paketet med hjälp av kommandot exec subsystem i stället för SSIS-undersystemkommandot.

Om SSIS-loggning

Med SSIS-loggning och loggproviders kan du samla in information om paketkörning och -fel. Som standard loggar inte paketet information. Du måste konfigurera paketet för att logga information. När du konfigurerar paketet för att logga information visas detaljerad information som liknar följande. I det här fallet vet du att det är ett behörighetsproblem:

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.

Om kommandot och utdatainformationen för exec-undersystemet

Med hjälp av kommandometoden exec-undersystem lägger du till utförliga konsolloggningsväxlar till SSIS-kommandoraden för att anropa den körbara filen Dtexec.exe SSIS-kommandoraden. Dessutom använder du funktionen Avancerat jobb i utdatafilen. Du kan också använda alternativet Inkludera stegutdata i historiken för att omdirigera loggningsinformationen till en fil eller till SQL Server Agent-jobbhistoriken.

Följande är ett exempel på en kommandorad:

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

Konsolloggningen returnerar information som liknar följande:

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

Referenser

Tyvärr är användarna inte medvetna om att standardinställningarna för agentjobbet placerar dem i det här tillståndet. Mer information om SQL Server Agent-proxyservrar och SSIS finns i följande avsnitt i SQL Server 2005 Books Online:

  • Schemaläggning av paketkörning i SQL Server Agent
  • Skapa SQL Server Agent-proxyservrar