Integration Services Catalog – Wenn die Validierung nicht will….

Oder auch: DTS_E_OLEDBERROR. An OLE DB error has occurred. Error Code: 0x80004005

Hallo zusammen,

heute will ich kurz über ein Problem berichten, welches mich doch einige Stunden an Recherche gekostet hat.

Ich bin inzwischen ein Fan der Integration Services Catalogs. Es macht die Bereitstellung von SSIS Paketen / Projekten doch recht einfach und die Parametrisierung ist nahezu ein Kinderspiel. Wie schnell so ein Katalog eingerichtet ist hat Mark Broadbent vor Kurzem gebloggt: https://tenbulls.co.uk/2017/04/27/deploying-ssiscat/ .

Vor Allem gefällt mir, dass ich nun ohne großen Mehraufwand auch direkt auf ein Projekt im Katalog Berechtigungen vergeben kann. Oder aber ich setze direkt auf mehrere Projekte die Berechtigungen, indem ich auf einen übergeordneten Ordner die Berechtigungen vergebe. Je nachdem für welchen Aufbau ich mich entschieden habe.

SSISDB:

Ordner:

Projekt:

 

Jetzt hatte ich vor Kurzem folgende Situation:

Ein Benutzer hatte das Projekt …V2 abgelegt bzw. hatte ich die Vorbereitungen getroffen, dass der Benutzer auf dem Projektordner die Berechtigungen Read, Modify und Execute hat. Wie auch auf dem Screenshot ersichtlich. Eine Bereitstellung ist kein Problem gewesen. Aber: die Validierung eines bestimmten Paketes schlug immer fehl:

Wenn ich mit meinem Konto das Projekt bzw. das besagte Paket validierte, dann war alles in Ordnung.

Bei dem besagten Paket war eine der verwendeten Datenquellen eine Exceldatei. Zuerst war ja mein Verdacht, dass es irgendwas mit dem Microsoft.ACE.OLEDB.12.0 Treiber zu tun hatte. Bei einer Meldung wie DTS_E_OLEDBERROR nicht ganz abwegig… Aber ich konnte mit meinem Konto das Paket problemlos prüfen. Also weiter ran getastet. Die Zugriffe auf den UNC Pfad, wo die Quelldatei lag, waren ebenfalls korrekt gesetzt.

Es gab aber auf dem Host System, wo der SSIS Katalog lag, einen Unterschied zwischen den Berechtigungen der unterschiedlichen Benutzerkonten: ich war lokaler Admin, der andere Benutzer eben nicht.

Hierzu sei auch einmal schnell erwähnt: im Normalfall sollten die Rollen Windows Admin und SQL Server Admin getrennt sein. Im Falle der Entwicklungsumgebung hatte ich hier aber eine Ausnahme gemacht.

Ich habe dann den Benutzer mal in die Gruppe der Remote Desktop Benutzer aufgenommen, sodass er sich auf den Server anmelden konnte. Dann eben auf den Katalog verbunden und das Paket validiert: das ging problemlos.

Dann die Validierung vom lokalen Management Studio wieder angeworfen: Validierung ebenfalls erfolgreich. Danach den Benutzer wieder abgemeldet und nur vom lokalen Client aus die Validierung angestoßen: es schlug wieder fehl mit dem altbekannten Fehler.

Um nun dem Fehler weiter auf die Schliche zu kommen habe ich mich des Tools Process Monitor aus der SysInternals Suite bedient. Mit dem Tool lassen sich ja eine Unmenge an Prozessaktivitäten, Dateizugriffen und Ähnlichem in Echtzeit überwachen.

Also hatte ich kurz den ProcMon angeworfen, die Validierung vom lokalen Client angestoßen und dann die Zeitstempel der Validierung mit der ProcMon Ausgabe abgeglichen. Und da bin ich endlich fündig geworden:

Es wurde ein ACCESS DENIED Fehler geworfen bei einer CreateFile Operation unter C:\Users\Default\AppData\Local\Microsoft\Windows\InetCache\Content.MSO\…

Warum jetzt auf das Default user Profile zurückgegriffen wurde konnte ich bis gerade nicht sagen. Wo ich aber gerade diesen Artikel schreibe und noch mal quer gegoogelt habe, bin ich auf folgenden Post

http://www.alankoo.com/2012/09/strange-error-loading-excel-files-xlsx.html

und einer ganz wichtigen Aussage gestoßen:“…ACE uses the impersonated user’s Windows temp folder to read-write its data. Therefore if your application is using impersonation with an account that does not have a profile on the server (not an uncommon situation), then ACE will not be able to create its temp files.”

Das bedeutet also auch, wenn ich mit meinem lokalen Management Studio remote einen SSIS Katalog prüfe, dann habe ich zu dem Zeitpunkt auf dem Server eben auch kein valides Profil.

Im Nachgang habe ich mir auf dem Server eine entsprechende SSIS_User Gruppe angelegt. Hier dann meinen Testbenutzer und das Konto des Entwicklers hinzugefügt und Schreibberechtigungen auf ..\Content.MSO gegeben.  Dies war für mich die Lösung, damit ein Paket oder Projekt problemlos remote validiert werden kann.

Falls jemand hier eine andere, ggf. sogar bessere Lösung kennt, dann immer her damit. Ich werde dies nachgelagert festhalten.

 

Lesson learned von meiner Seite:

doch mal genauer schauen, was so bei den Downloads geschrieben steht:

und die Leute überzeugen ggf. doch eher CSVs zu verwenden. Das macht weniger Umstände ;-)