Je souhaite exécuter un package SSIS contenant des tâches de transfert d'objets SQL Server. Les serveurs impliqués sont sur le même domaine, mais les services SQL Server s'exécutent sur des comptes de service locaux. L'environnement ressemble donc à ceci:
Domaine
Serveur 1
- SQL Server exécuté sur un compte local
- Sur le système de fichiers: package SSIS
- Dans l'Agent SQL Server: un travail
Serveur 2
- SQL Server exécuté sur un compte local
Pour pouvoir me connecter aux deux serveurs, j'ai créé un compte de domaine à utiliser comme compte de service. Lorsque j'utilise ce compte de domaine pour me connecter au serveur 1, puis exécuter le package à partir du système de fichiers, chaque étape réussit. Cependant, lorsque j'essaie d'ajouter le travail à SQL Server, je rencontre l'un des problèmes suivants:
Situation 1. Propriétaire de l'emploi: compte local; exécutez l'étape SSIS en tant que proxy pour le compte de domaine . Lorsque je définis le propriétaire du travail sur un compte local, mais que j'exécute le travail en tant que proxy sur le compte de domaine, le travail lui-même s'exécute avec succès, mais le package renvoie des erreurs comme
L'exécution a échoué avec l'erreur suivante: "Le répertoire 'LocalApplicationData' n'existe pas.".
Cette erreur peut être corrigée en créant une connexion avec des droits d'administrateur pour l'utilisateur de domaine sur le serveur 1, mais ce n'est évidemment pas une solution souhaitable. L'ajout du compte à l'un des groupes d'agent SQL Server / DTS ne fonctionne pas non plus.
Situation 2. Propriétaire de l'emploi: compte de domaine; exécutez l'étape SSIS en tant que proxy pour le compte de domaine . Lorsque je définis à la fois le propriétaire du travail et le «exécuter en tant qu'utilisateur» pour l'étape sur le compte de domaine, le travail ne démarre pas du tout, avec l'erreur suivante:
Impossible de déterminer si le propriétaire (domaine \ utilisateur de domaine) du travail
Job namea accès au serveur (raison: impossible d'obtenir des informations sur le groupe / utilisateur Windows NT 'Utilisateur de domaine \ utilisateur', code d'erreur 0x5. [SQLSTATE 42000] (erreur 15404)) .
Je crois que la dernière erreur est due au fait que SQL Server s'exécute sur un compte local et ne peut donc pas déterminer les droits des comptes de domaine.
Quelle est la bonne façon de faire fonctionner le travail? La situation 2 me semble plus propre, mais semble impossible car SQL Server s'exécute sur un compte local. La situation 1 fonctionnerait également, mais donner des droits administratifs à un utilisateur de domaine sur mon serveur SQL ne se produira pas.
MISE À JOUR:
@ JonSeigel et @ Mr.Brownstone:
Il semble plausible que ce problème soit dû au manque d'autorisations. Cependant, l'erreur concerne l'inexistence de «LocalApplicationData» - l'un des dossiers qui est généré pour chaque compte. Je me suis déjà connecté au serveur avec les informations d'identification sous lesquelles le package s'exécute (créant ainsi un répertoire de profil) et j'ai essayé plusieurs combinaisons d'autorisations pour le répertoire de profil. Même lorsque j'accorde manuellement presque toutes les autorisations sur ce répertoire spécifique, j'obtiens l'erreur mentionnée ci-dessus.
Tout en faisant des recherches supplémentaires, je suis tombé sur un fil de discussion sur http://www.sqlservercentral.com/Forums/Topic391332-148-1.aspx#bm391441 qui est assez similaire - sans solution non plus.