SSIS-Verbindung zu SQL-Server

[Tommi]

Hallo zusammen,

ich hätte da gern mal ein Problem... und zwar folgendes:

ich baue gerade ein SSIS-Paket für eine Test-Umgebung, bei der mir jetzt ein Phänomen unterkommt, das ich echt noch nicht erlebt habe (und ich mach den Scheiß schon lange!)

In dem Paket habe ich eine Connection zu einem Server eingerichtet, Zugriff über SQL Server Account (kein AD-User!) Der Server ist ein SQL-Server 2016 (64bit).

Wenn ich nun im SSIS-Paket im Datenflusstask eine OLE-DB Source hinzufüge und die eingerichtete Connection auswähle, kann ich die Metadaten der dort ausgewählten Tabelle sehen und eine entsprechende Spaltenzuordnung wird mir angezeigt. Auch eine Datenvorschau kann ich mir anzeigen lassen - funktioniert einwandfrei - Connection funktioniert also.

Ich habe zum Test jetzt mal ganz einfach den Inhalt von Quelle.Tabelle in Ziel.Tabelle geschoben, wobei die Ziel-Tabelle den gleichen Aufbau wie die Quelle hat. Das Ziel liegt aber natürlich auf einem anderen Server und (hier liegt evtl. das Problem - siehe unten) in einer anderen Domain,
Der Ziel-Server ist ein SQL Server 2019(64bit), Entwicklungsumgebung ist Visual Studio 2019 (auch 64bit) und 64bit-Betriebssystem Windows 10. Ziel-Server und Entwicklungsumgebung laufen auf der gleichen Maschine.

Wenn ich jetzt in der Entwicklungsumgebung den Task im Debug-Modus ausführen will, erhalte ich folgende Fehlermeldung:

Fehler: SSIS-Fehlercode "DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER". Fehler beim Aufrufen der AcquireConnection-Methode über den Verbindungs-Manager "[Quelle]" (Fehlercode: 0xC0202009). Möglicherweise wurden bereits Fehlermeldungen veröffentlicht, die weitere Informationen zum Fehler beim Aufrufen der AcquireConnection-Methode beinhalten.


Meine Suche im Internet hat bisher nicht wirklich was ergeben. Der Fehler wird immer mit eine Excel-Connection in Verbindung gebracht - das habe ich aber ja nicht - ist ja eine direkte Verbindung zu einem SQL-Server. (habe in der Connection auch schon mehrere OLE-DB-Treiber ausprobiert - überall die gleiche Fehlermeldung).

Ich habe zwar eine Vermutung, woran es liegen könnte, da ich die Fehlermeldung aber auch in der Entwicklungsumgebung (Visual Studio 2019) bekomme, bin ich etwas verwirrt, da die Connection zum Auslesen ja die Metadaten mit den hinterlegten Credentials zurückgibt. Der Quell-Server liegt in einer anderen Domain. Ich komme zwar an den Server dran, aber die Namensauflösung funktioniert über die Domain-Grenzen nicht. Daher spreche ich die Instanz über [IP-Adresse]\Instanzname an. Meine Vermutung ist nun, dass einige Ports Domain-Übergreifend gesperrt sind. Da ich aber ansonsten alles an dem besagten SQL-Server machen kann sowohl im SSMS und auch im Visual Studio, bin ich total verwirrt.

Hat jemand von euch schon einmal ein ähnliches Problem gehabt oder weiß vielleicht eine Quelle, in der ich dazu mehr lesen und erfahren kann?

Viele Grüße,
ein verwirrter Tommi...

 

[Tommi]

Hallo zusammen,

meine Verwirrung hat sich gelöst - habe jetzt endlich gefunden, woran das lag. Eigentlich, wenn man im nachhinein drüber nachdenkt, sogar logisch - hätte man direkt drauf kommen können.
Aber wie so oft schaut man erst ganz am Schluss auf das, was man eigentlich voraussetzt und normalerweise Standard ist...

Problem lag am ProtectionLevel des SSIS-Projekts und der Pakete.
Im Standard ist dieser auf den Wert "EncryptSensitiveWithUserKey" gesetzt.

Ich habe die Pakete jedoch von einem Kollegen übernommen, der diese auf einer Umgebung implementiert hat, in der alle Systeme innerhalb einer Domain arbeiten und die Verbindung zu den Datenbanken (Quelle und Ziel) über integrierte Sicherheit eingerichtet war.
Daher war der Kollege wohl der Meinung (leider nicht mehr verfügbar für Nachfragen), dass man den ProtectionLevel auf den Wert "DontSaveSensitive" setzten kann, da ja soundso kein Passwort gespeichert wird.

Mit diesem Protectionlevel wird aber VERHINDERT, dass ein Passwort im Paket gespeichert wird. Daher konnte meine Verbindung zur Datenbank, die ja Domian-Übergreifend ist und daher mit einem SQL-Account inkl. Passwort vorgenommen werden muss, auch nicht hergestellt werden, da halt kein Passwort bei Ausführung zur Verfügung stand (war ja nicht im Paket gespeichert).

Habe ich natürlich als letztes draufgeschaut, da auch bei integrierter Sicherheit es keinen Sinn macht, vom Standard-Protection-Level abzuweichen.

Jetzt ist alles umgestellt (man muss dann jedes Paket im SSIS-Projekt anpacken und das umstellen - geht leider nicht direkt für alle) und siehe da - es geht! Kaum macht man's richtig....

Viele Grüße,
ein nicht mehr verwirrter Tommi.