2009-12-15 25 views
4

SQL Server Reporting Services, dans SSRS, il semble que les planifications ne se déclenchent jamais, mais un examen de l'Agent SQL révèle un problème d'autorisation lié à ne pas être en mesure de résoudre un compte d'utilisateur.SSRS - Impossible de déterminer si le propriétaire du travail a accès au serveur [SQLSTATE 42000] (Erreur 15404))

Semble SQL Agent ne repose pas sur la mise en cache ou quoi que ce soit Windows magiquement fonctionne.

link text Fix est répertorié ici ... modifier -

ci-dessus est la solution que je l'habitude de contourner ce problème, a trouvé une tout autre travail ou de contournements résolutions à ce sujet?

Il semble que, par défaut, les horaires générés par SSRS sont exécutés comme ce compte d'utilisateur fantôme. Comment changer cette valeur par défaut? SSRS crée-t-il les travaux en tant qu'utilisateur du service?

Merci Remus

+0

Personnellement, je ne recommanderais pas le lien que vous avez fourni, car il ne fait que contourner ce que vous pouvez faire avec le Gestionnaire de configuration de Report Services. Je pense qu'il est préférable de simplement modifier le compte de service Report Server à l'aide de RS Config Manager. C'était l'intégrité de la base de données est maintenue – openshac

Répondre

2

15404 est l'exception quand EXECUTE AS contexte ne peut être personnifié. Les raisons de ces erreurs sont nombreuses. Les raisons les plus courantes sont:

  • lorsque l'instance SQL Server n'a pas accès au serveur AD car est en cours d'exécution en tant qu'utilisateur local ou « service local » (ce qui aurait un code d'erreur 0x5, ACCESS_DENIED)
  • lorsque le serveur SQL est invité à usurper l'identité d'un utilisateur inconnu, comme un utilisateur d'un domaine du serveur SQL n'a pas idée (cela aurait le code d'erreur 0x54b, ERROR_NO_SUCH_DOMAIN)

la bonne solution est toujours dépendante sur le code d'erreur, qui est l'erreur du système d'exploitation lorsque vous essayez d'obtenir le jeton d'identité d'utilisateur emprunté: rches d'abord pour le code d'erreur dans la table System Error Codes (ou allume windbg, fait une connexion de débogage de noyau non-invasive de loopback et va! error, qui est ce que je préfère cause est plus rapide ...). Alors, John ... avez-vous une question, ou vous venez de publier une information partielle au hasard?

7

Je courais dans le même problème. Voici comment je l'ai réparé.

Description du problème Lors de la définition d'un abonnement à un rapport de SSRS à courir à un moment donné, j'attendrais le temps de passer et de trouver que l'horodatage « Last Run » n'a pas changé. Mon abonnement semble ne pas avoir fonctionné.

informations de dépannage pertinentes

  1. abonnements rapport de SSRS sont exécutées comme Jobs SQL que l'interface utilisateur Web Report Server crée pour vous dans les coulisses.

  2. Lorsque l'on regarde le travail qui a été créé pour mon abonnement à un rapport, j'ai vu qu'il a toujours échoué avec l'erreur:

    The job failed. Unable to determine if the owner (domain\userName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user 'domain\userName', error code 0x5. [SQLSTATE 42000] (Error 15404)).

  3. Dans le SQL Server Configuration Manager, je pouvais voir que le « SQL Server Le service Reporting Services a été configuré pour s'exécuter à l'aide d'un compte d'utilisateur AD.

  4. Dans le Gestionnaire de configuration Sql Server, je pouvais voir que le service "SQL Server" était configuré pour s'exécuter en utilisant un compte Windows local . Comme l'a souligné @Remus Resanu, l'erreur SQL 15404 fait référence à une exception lorsque le contexte EXECUTE AS ne peut pas être emprunté.

Solution Bingo! # 4 et # 5 sont la clé du problème. Le service SQL Server (un compte d'utilisateur Windows local) essayait d'authentifier l'utilisateur "domain \ userName" dans AD, ce qu'il ne pouvait pas faire parce qu'il n'a pas le droit/l'autorisation d'accéder aux ressources AD.

J'ai changé le service SQL Server pour nous un compte d'utilisateur AD, redémarré les services SQL Server et SQL Server Agent, réexécuté le travail SQL et, blamo, succès!