Beim Aufrufen aus einem SQL Server-Agentauftragsschritt wird ein SSIS-Paket nicht ausgeführt

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 918760 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
918760 An SSIS package does not run when you call the SSIS package from a SQL Server Agent job step
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Problembeschreibung

Wenn Sie ein SSIS-Paket (Microsoft SQL Server 2005 Integration Services) aus einem SQL Server-Agentauftragsschritt heraus aufrufen, wird es nicht ausgeführt. Sofern Sie das SSIS-Paket nicht verändern, lässt es sich außerhalb des SQL Server-Agents ausführen.

Ursache

Dieses Problem tritt auf, wenn eine der folgenden Bedingungen vorliegt:
  • Das Benutzerkonto, mit dem das Paket unter dem SQL Server-Agent ausgeführt wird, ist nicht dasselbe wie das des ursprünglichen Paketautors.
  • Das Benutzerkonto verfügt nicht über die erforderlichen Berechtigungen für Verbindungen oder für den Zugriff auf Ressourcen außerhalb des SSIS-Pakets.
In den folgenden Szenarien wird das Paket möglicherweise nicht ausgeführt:
  • Der aktuelle Benutzer kann keine geheimen Daten aus dem Paket entschlüsseln. Dieses Szenario kann eintreten, wenn das aktuelle Konto oder das Ausführungskonto nicht mit dem ursprünglichen Paketautor übereinstimmen oder wenn die Einstellung der ProtectionLevel-Eigenschaft für das Paket nicht zulässt, dass der aktuelle Benutzer geheime Daten im Paket entschlüsselt.
  • Eine SQL Server-Verbindung, die integrierte Sicherheit nutzt, kann nicht hergestellt werden, weil der aktuelle Benutzer nicht über die erforderlichen Berechtigungen verfügt.
  • Der Dateizugriff schlägt fehl, weil der aktuelle Benutzer nicht über die erforderlichen Berechtigungen zum Schreiben in die Dateifreigabe verfügt, auf die der Verbindungs-Manager zugreift. Dieses Szenario kann beispielsweise eintreten, wenn Textprotokollanbieter keinen Benutzernamen und kein Kennwort verwenden. Es kann ebenfalls eintreten bei Aufgaben, die vom Dateiverbindungs-Manager abhängig sind, beispielsweise bei einer SSIS-Dateisystemaufgabe.
  • Eine registrierungsbasierte SSIS-Paketkonfiguration verwendet die HKEY_CURRENT_USER-Registrierungsschlüssel. Die HKEY_CURRENT_USER-Registrierungsschlüssel sind benutzerspezifisch.
  • Für eine Aufgabe oder einen Verbindungs-Manager benötigt das aktuelle Benutzerkonto die richtigen Berechtigungen.

Lösung

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu beheben. Welche Methode am besten geeignet ist, ist abhängig von der Umgebung, in der der Paketfehler aufgetreten ist, und dessen Ursache.

Methode 1: Verwenden eines SQL Server-Agentproxykontos

Erstellen Sie ein SQL Server-Agentproxykonto. Dieses Proxykonto muss Anmeldeinformationen verwenden, mit denen der SQL Server-Agent den Auftrag als das Konto ausführen kann, mit dem das Paket erstellt wurde, oder als ein Konto mit den erforderlichen Berechtigungen.

Diese Methode ist zum Entschlüsseln von geheimen Daten geeignet und wird den wichtigsten Benutzeranforderungen gerecht. Die Methode ist möglicherweise jedoch nur bedingt erfolgreich, da die Benutzerschlüssel für das SSIS-Paket den aktuellen Benutzer und den aktuellen Computer enthalten. Wenn das Paket auf einen anderen Computer verschoben wird, kann der Fehler bei dieser Methode dennoch auftreten, obwohl der Auftragsschritt das richtige Proxykonto verwendet.

Methode 2: Festlegen der "ProtectionLevel"-Eigenschaft des SSIS-Pakets auf ServerStorage

Ändern Sie die ProtectionLevel-Eigenschaft des SSIS-Pakets in ServerStorage. Mit dieser Einstellung wird das Paket in einer SQL Server-Datenbank gespeichert und die Zugriffssteuerung über SQL Server-Datenbankrollen ermöglicht.

Methode 3: Festlegen der "ProtectionLevel"-Eigenschaft des SSIS-Pakets auf EncryptSensitiveWithPassword

Ändern Sie die ProtectionLevel-Eigenschaft des SSIS-Pakets in EncryptSensitiveWithPassword. Bei dieser Einstellung wird ein Kennwort zur Verschlüsselung verwendet. Anschließend können Sie die Befehlszeile für den SQL Server-Agentauftragsschritt verändern und dieses Kennwort hinzufügen.

Methode 4: Verwenden von SSIS-Paketkonfigurationsdateien

Verwenden Sie SSIS-Paketkonfigurationsdateien zum Speichern vertraulicher Informationen. Speichern Sie die Konfigurationsdateien anschließend in einem gesicherten Ordner. Anschließend können Sie die ProtectionLevel-Eigenschaft in DontSaveSensitive ändern, sodass das Paket nicht verschlüsselt wird und nicht versucht, geheime Daten im Paket zu speichern. Beim Ausführen des SSIS-Pakets werden die erforderlichen Informationen aus der Konfigurationsdatei geladen. Stellen Sie sicher, dass die Konfigurationsdateien angemessen geschützt sind, falls sie vertrauliche Informationen enthalten.

Methode 5: Erstellen einer Paketvorlage

Eine langfristige Lösung ist das Erstellen einer Paketvorlage mit einer Schutzebene, die von der Standardeinstellung abweicht. In zukünftigen Paketen tritt das Problem nicht mehr auf.

Status

Es handelt sich hierbei um ein beabsichtigtes Verhalten.

Weitere Informationen

Schritte zum Reproduzieren des Problems

  1. Melden Sie sich als Benutzer an, der nicht Mitglied der Gruppe SQLServer2005SQLAgentUser ist. Sie können beispielsweise einen lokalen Benutzer erstellen.
  2. Erstellen Sie ein SSIS-Paket, und fügen Sie eine ExecuteSQL-Aufgabe hinzu. Nutzen Sie mit der folgenden Zeichenfolge einen OLE DB-Verbindungs-Manager zur lokalen MSDB-Datei: "Windows-Authentifizierung" -SQLSourceType: "Direkteingabe" -SQLStatement: "sp_who"
  3. Führen Sie das Paket aus, um zu überprüfen, ob es funktioniert.
  4. Beachten Sie, dass die ProtectionLevel-Eigenschaft auf EncryptSensitiveWithPassword festgelegt ist.
  5. Erstellen Sie einen SQL Server-Agentauftrag und einen Auftragsschritt. Klicken Sie in der Liste Ausführen als auf SQL Server-Agent-Dienst, um den Auftragsschritt auszuführen.
Der Auftragsverlauf des SQL Server-Agents enthält Informationen etwa folgender Art:

Ausgeführt als Benutzer: DOMÄNE\BENUTZERNAME. Fehler beim Ausführen des Pakets. Fehler bei Schritt.

Entschlüsseln von geheimen Daten im Paket

Die Standardeinstellung für die ProtectionLevel-Eigenschaft des SSIS-Pakets ist EncryptSensitiveWithUserKey. Beim Speichern des Pakets werden von SSIS nur die Teile des Pakets verschlüsselt, die als "vertraulich" gekennzeichnete Eigenschaften enthalten, z. B. Kennwörter, Benutzernamen und Verbindungszeichenfolgen. Beim erneuten Laden des Pakets muss der aktuelle Benutzer daher die Verschlüsselungsanforderungen erfüllen, damit die vertraulichen Eigenschaften entschlüsselt werden. Zum Laden des Pakets muss der aktuelle Benutzer die Verschlüsselungsanforderungen jedoch nicht erfüllen. Wenn Sie das Paket aus einem SQL Server-Agentauftragsschritt heraus ausführen, ist das Konto "SQL Server-Agent-Dienst" das Standardkonto. Bei diesem Standardkonto handelt es sich mit großer Wahrscheinlichkeit um einen anderen Benutzer als den Paketautor. Aus diesem Grund kann der SQL Server-Agentauftragsschritt zwar geladen und gestartet werden, das Paket verursacht aber einen Fehler, weil keine Verbindung hergestellt werden kann. Beispielsweise kann das Paket keine vollständige OLE DB- oder FTP-Verbindung herstellen. Das Paket verursacht einen Fehler, weil die für die Verbindung benötigten Anmeldeinformationen nicht entschlüsselt werden können.

Wichtig: Berücksichtigen Sie bei der Ermittlung der auf jedem Computer benötigten und verwendeten Konten den Entwicklungsprozess und die Umgebung. Die Einstellung EncryptSensitiveWithUserKey für die ProtectionLevel-Eigenschaft ist äußerst leistungsstark. Sie sollte nicht als negativ eingeschätzt werden, nur weil sie zunächst Komplikationen bei der Bereitstellung verursacht. Sie können die Pakete verschlüsseln, wenn Sie sich mit einem entsprechenden Konto anmelden. Sie können auch das SSIS-Befehlszeilenprogramm "Dtutil.exe" verwenden, um die Schutzebenen mithilfe einer CMD-Datei und des SQL Server-Agentbefehlssubsystems zu ändern. Gehen Sie hierzu beispielsweise folgendermaßen vor. Da Sie das Dienstprogramm "Dtutil.exe" in Batchdateien und Schleifen verwenden können, können Sie diese Schritte für mehrere Pakete gleichzeitig ausführen.
  1. Ändern Sie das Paket, das Sie mit einem Kennwort verschlüsseln möchten.
  2. Verwenden Sie das Dienstprogramm "Dtutil.exe" über einen Betriebssystem (cmd Exec)-SQL Server-Agentauftragsschritt, um die ProtectionLevel-Eigenschaft in EncryptSensitiveWithUserKey zu ändern. Bei diesem Prozess wird das Paket unter Verwendung des Kennworts entschlüsselt und anschließend erneut verschlüsselt. Der zur Verschlüsselung des Pakets verwendete Benutzerschlüssel ist die in der Liste Ausführen als gewählte Einstellung für den SQL Server-Agentauftragsschritt.

    Hinweis: Da der Schlüssel den Benutzer- und den Computernamen enthält, kann diese Methode beim Verschieben des Pakets auf einen anderen Computer wirkungslos sein.

Sicherstellen, dass ausführliche Informationen über den SSIS-Paketfehler vorliegen

Anstatt mit dem Auftragsverlauf des SQL Server-Agents mit seinen unzureichenden Details können Sie mithilfe der SSIS-Protokollierung sicherstellen, dass Sie über umfassende Informationen über den SSIS-Paketfehler verfügen. Sie können das Paket auch mit dem exec-Subsystembefehl anstelle des SSIS-Subsystembefehls ausführen.

Informationen zur SSIS-Protokollierung

Mithilfe der SSIS-Protokollierung und Protokollanbietern können Sie Details über die Paketausführung und mögliche Fehler erfassen. Standardmäßig werden vom Paket keine Informationen protokolliert. Sie müssen die Protokollierung im Paket konfigurieren. Wenn Sie im Paket die Protokollierung einrichten, werden ausführliche Informationen etwa folgender Art angezeigt. In diesem Fall wissen Sie, dass es sich um ein Problem mit unzureichenden Berechtigungen handelt:

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,Mithilfe von "FTP-Verbindungs-Manager" kann keine Verbindung mit dem FTP-Server hergestellt werden.

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,Fehler beim Abrufen der Verbindung "user01.msdb". Die Verbindung ist möglicherweise nicht ordnungsgemäß konfiguriert, oder Sie haben nicht die richtigen Berechtigungen für diese Verbindung.

Informationen zum exec-Subsystembefehl und zur Ausgabe

Mithilfe des exec-Subsystembefehls können Sie der SSIS-Befehlszeile Befehlszeilenoptionen für eine ausführliche Konsolenprotokollierung hinzufügen, um die ausführbare SSIS-Befehlszeilendatei "Dtexec.exe" aufzurufen. Außerdem können Sie das erweiterte Auftragsfeature der Ausgabedatei verwenden. Mithilfe der Option Include Step Output in the history (Ergebnis in Verlauf einschließen) können Sie die Protokollinformationen in eine Datei oder in den Auftragsverlauf des SQL Server-Agents umleiten.

Beispiel für eine Befehlszeile:

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


Die Befehlszeilenoption /console gibt Details etwa folgender Art zurück:

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

Informationsquellen

Weitere Informationen zu einem ähnlichen Problem finden Sie im folgenden Artikel der Microsoft Knowledge Base:
904800 Wenn Sie versuchen, ein SQL Server 2005 Integration Services Paket in SQL Server 2005 auszuführen, wird eine Fehlermeldung "Fehler bei Laden" Ihnen angezeigt
Weitere Informationen zum Verwenden des Programms "Dtutil.exe" für Batchvorgänge finden Sie im folgenden Artikel der Microsoft Knowledge Base:
906562 Wie Verwenden des Dienstprogramms Dtutil (Dtutil.exe) um den Schutzgrad eines Batches der Pakete SQL Server Integration Services (SSIS) in SQL Server 2005 festzulegen
Weitere Informationen zur Erstellung von Paketvorlagen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
908018 Erstellen einer Paketvorlage in SQL Server Business Intelligence Development Studio


Weitere Informationen zur Sicherheit von SSIS-Paketen und zur ProtectionLevel-Eigenschaft finden Sie in der SQL Server 2005-Onlinedokumentation im Thema zu Sicherheitsüberlegungen für Integration Services.

Unglücklicherweise sind sich die Benutzer nicht bewusst, dass die Standardeinstellungen für Agentauftragsschritte diesen Zustand verursachen. Weitere Informationen über SQL Server-Agentproxys und SSIS finden Sie in den folgenden Themen der SQL Server 2005-Onlinedokumentation:
  • Planen der Paketausführung im SQL Server-Agent
  • Erstellen von SQL Server-Agentproxys

Eigenschaften

Artikel-ID: 918760 - Geändert am: Freitag, 12. Juli 2013 - Version: 2.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2008 Service Pack 1
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2005 Service Pack 3
  • Microsoft SQL Server 2005 Service Pack 2
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems
Keywords: 
kbsqlsetup kbprb kbsql2005ssis kbsql2005setup kbexpertiseinter kbexpertiseadvanced kbtshoot KB918760
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com