Quelles informations d'identification d'utilisateur les services D'intégration cataloguent - ils pour exécuter des paquets?
nous avons un paquet SSIS qui lit les fichiers texte d'un répertoire réseau partagé. Quand j'exécute ce paquet dans SSDT ça marche très bien. Lorsque nous déployons le projet vers le Integration Services Catalog et tentons d'exécuter le même paquet à partir de là, je reçois une erreur indiquant que l'accès au répertoire est refusé.
j'ai toujours eu l'impression que lorsque je me connecte à la base de données et exécute un paquet SSIS à partir des services D'intégration Cataloguez qu'il utilise mes identifiants d'utilisateur et aurait ainsi accès au répertoire en question car mon profil d'utilisateur y a accès.
n'est-ce pas? Est-ce que SQL Server utilise un utilisateur différent pour exécuter des paquets du catalogue IS? Est-il une option pour run as another user ? Toute contribution sera appréciée.
3 réponses
Package Exécutions:
Outils de Données SQL Server:
identification de l'Utilisateur en vertu de laquelle SQL Server Data Tools (SSDT) est l'exploitation sera utilisé pour exécuter les packages qui sont exécutées à l'intérieur de SSDT.
sous Windows Start \ tous les programmes \ Microsoft SQL Server 2012, si vous cliquez sur SQL Server Data Tools, il fonctionnera sous vos justificatifs d'identité. Pour exécuter sous un compte utilisateur différent, vous pouvez appuyer Ctrl + Shift pour sélectionner Run as different user option.
Intégration De Services Du Catalogue:
lorsque vous faites un clic droit sur un paquet sous Integration Services Catalog \ SSISDB \ <Folder name> \ Projects \ <Project name> \ Packages \ <Package name> et sélectionnez Execute... pour exécuter un paquet. Le paquet s'exécute sous les identifiants utilisés pour se connecter à SQL Server Management Studio.
notez que si vous essayez d'exécuter un paquet en utilisant L'authentification SQL Server, vous obtiendrez le message d'erreur suivant:
l'opération ne peut pas être lancée par un compte qui utilise L'authentification SQL Server. Démarrer avec un compte qui utilise l'Authentification Windows.
après avoir appuyé sur Execute... , SQL Server spins a processus ISServerExec.exe , qui lance un Console Window Host processus:
ISServerExec.exe est un programme qui exécute des paquets dans le catalogue SSIS. Dans ce cas, il est lancé par le même utilisateur qui exécute un paquet SSIS depuis SQL Server Management Studio.
SQL Server Agent Job Without Proxy:
lorsque vous exécutez un paquet SSIS à partir d'un serveur SQL Agent Job , le travail étape par défaut fonctionne sous SQL Server Agent Service Account . Le service SQL Server Agent associé au compte utilisateur peut être trouvé en naviguant sur Windows Start \ Administrative Tools \ Services , recherchez L'Agent de service SQL Server ( Your Instance Name ) et trouvez le compte utilisateur indiqué sous Log On As
SQL Server Agent Job With Proxy:
vous pouvez également exécuter un Agent de serveur SQL Emploi sous différents titres en créant un compte mandataire. Lorsque des étapes de travail sont exécutées sous le compte proxy, le paquet dans l'étape de travail s'exécutera sous le justificatif spécifié sur le compte proxy.
ci-dessous, ainsi la réponse fournit des instructions étape par étape pour créer un compte proxy pour exécuter des tâches D'Agent SQL Server.
comment créer une étape dans mon travail D'Agent SQL Server qui exécutera mon paquet SSIS?
Comment vérifier:
Échantillon SSIS 2012:
voici ce que j'ai fait pour vérifier les déclarations ci-dessus en ce qui concerne les comptes d'utilisateur utilisés pour les exécutions de paquets.
-
Ouvrez Outils de Données SQL Server et créer et SSIS 2012 package nommé
SO_15289442.dtsx. -
créer une variable nommée
ExecutionUserde données tapezString. Assignez l'expression@[System::UserName]à la variable.UserNameest une variable système qui fournit les informations de l'utilisateur exécutant le paquet. -
Glisser-déposer Tâche Envoyer un message sur le Flux de Données onglet.
-
créer une connexion SMTP et l'attribuer à la
SmtpConnectionsur la Tâche Envoyer un message à l'Éditeur de Messagerie de la page. -
spécifiez les adresses courriel
FrometTo. -
changer le MessageSourceType en
Variable. -
Set
MessageSourceàUser::ExecutionUser. -
faites un clic droit sur le paquet et sélectionnez Déployer pour déployer le catalogue des Services D'intégration du projet disponible sur un serveur de votre choix.
Package exécutions
-
exécuter le colis dans SSDT.
-
Open SSDT en utilisant Run comme option utilisateur différente. Fournissez un autre justificatif d'identité que le vôtre et lancez le paquet à nouveau.
-
lancer le paquet du catalogue Integration Services.
-
créer une tâche SQL Server Agent pour exécuter le paquet en utilisant le compte SQL Server Agent Service.
-
créer une tâche SQL Server Agent pour exécuter le paquet en utilisant un compte proxy.
pour chaque exécution mentionnée ci-dessus, vous recevrez un e-mail avec le compte d'utilisateur qui a été utilisé pour exécuter le paquet.
Votre Problème:
dans votre cas, le paquet s'exécutera sous votre compte ( en supposant que vous utilisez vos justificatifs d'identité pour accéder à SSISDB ) si vous cliquez avec le bouton droit de la souris et sélectionnez Execute from Integration Services Catalog. Assurez-vous que le le dossier a accès au chemin réseau.
si vous exécutez votre paquet depuis le poste D'Agent de SQL Server, le compte proxy est l'option run as another user que vous recherchez.
on dirait que vous n'avez pas Kerberos configuré sur votre serveur SQL (problème de double hop).
voici le problème enregistré avec MS qui a été corrigé. https://connect.microsoft.com/SQLServer/feedback/details/767088/with-the-new-ability-to-execute-ssis-packages-from-tsql-kerberos-delegation-should-be-supported
Voici un excellent blog sur les détails de cette: http://www.sqlscientist.com/2014/01/setup-kerberos-authentication-for-sql.html
une fois cette option configurée, vous devriez pouvoir démarrer la tâche à distance en utilisant une procédure stockée ou un SSMS sur votre machine locale. Il passera vos identifiants s'il est configuré correctement, bien sûr vous devez vous assurer que vous avez les permissions appropriées pour accéder à la ressource réseau.
C'est un vieux thread, mais j'imagine que le problème que vous rencontrez est en fait le chemin d'accès au fichier. Utilisez-vous un nom UNC ou une lettre de lecteur? C'est-à-dire, est-ce que votre chemin de fichier quelque chose comme "Z:\path\to\file.csv" ou "\serveur\partage\chemin\fichier.csv"?
S'il s'agit d'une lettre de lecteur, elle fonctionnera très bien à partir de votre machine locale car vous avez ce lecteur mappé, mais échouera sur le serveur car la lettre de lecteur n'est pas mappée.