SSIS Pakete im SQL Server Agent unter einem eigenen User starten

Zur zeitzgesteuerten Verarbeitung von SSIS-Paketen bietet sich der beim SQL Server 2005 mitgelieferte SQL Server Agent an. Wie man im Screen Shot sieht, bietet der SQL Server Agent an, die SSIS-Pakete unter einem bestimmten User auszuführen. Diese Kombobox („Run as“) ist im Standard allerdings auf den Benutzer-Konto des SQL Server Agent-Dienstes beschränkt:

Als RunAs steht nur das Benutzerkonto des SQL Server Agents zur Verfügung

Hier möchte ich zeigen, wie man diese Kombobox um einen beliebigen User erweitern kann und somit auch ein Paket unter diesem User ausführen kann.

Dazu muss zunächst ein Credential (ein Windows-Konto samt Kennwort) angelegt werden und dieser dann für die Ausführung von SSIS-Paketen freigegeben werden.

Das Credential gibt man im SQL Server Management Studio (wenn man auf den relationalen Datenbank-Server verbunden ist) unter Security > Credentials ein, also z.B.:

Ein Credential wird angelegt

Unter SQL Server Agent > Proxies – also hier:

Eingabe Proxies– muss dieser Credential nun für die Ausführung von SSIS-Paketen definiert werden. Dazu erstellt man einen neuen Proxy unter einem beliebigen Namen, der das neu eingegebene Credential verwendet. Bei den erlaubten Subsystemen setzt man den Haken bei den SSIS-Paketen (und allen weiteren gewünschten Systemen):

Erstellen eines Proxies mit Erlaubnis für SSIS-Pakete

Und schon kann das Paket im SQL Server Agent unter diesem Proxy ausgeführt werden:

Ausführung des Jobs unter dem neu angelegten Proxy

Crash im Cube Designer

Bei mir kam es bei mehreren Installationen vor, dass die Entwicklung eines Cubes im Business Intelligence Development Studio (Visual Studio mit BI-Projektvorlagen) nicht vollständig funktionierte. Beim Klick auf den Tab zur Erstellung der berechneten Measures, stürzte entweder das Visual Studio komplett ab oder brachte eine Fehlermeldung.

Ein Forum-Eintrag in der MSDN besagt, dass die Dateien msmdlocal.dll und msmgdsrv.dll in den Verzeichnissen „%ProgramFiles%Microsoft Visual Studio 8Common7IDEPrivateAssemblies“ und „%ProgramFiles%Gemeinsame DateienSystemOle DB“ bzw. „%ProgramFiles%Common FilesSystemOle DB“ in unterschiedlichen Versionen vorliegen. Ich löschte (mit Backup 🙂 ) die Dateien in „%ProgramFiles%Gemeinsame DateienSystemOle DB“ und überschrieb sie mit den anderen Dateien. Dann funktionierte es wieder.

Bei mir trat das Problem reproduzierbar auf, als ich auf einem Rechner Excel 2003, Excel 2007 und SQL Server installierte. Die Reihenfolge der Installation spielte dabei keine Rolle.