Le compte proxy a échoué lors de l'exécution de SSIS via l'agent

Question

Récemment, lorsque j'ai créé un travail SQL Server Agent (2008) pour exécuter un package SSIS avec un compte proxy, il a échoué avec le message d'erreur ci-dessous. Quelle est cette exception? Quelles sont les causes et comment puis-je le résoudre?

Message d'erreur Exécuté en tant qu'utilisateur: blaw. Le processus n'a pas pu être créé pour l'étape 1 du travail 0xD5A5 (raison: un privilège requis n'est pas conservé par le client). L'étape a échoué.

Remarque: -Cela fonctionne correctement avec le compte de service d'agent.

Merci

Answer 1

Je suis en train d'obtenir que cela fonctionne en ce moment aussi bien. Vous essayez de regarder ces ressources?

http://support.microsoft.com/kb/918760

http://technet.microsoft.com/en-us/library/dd440761(SQL.100).aspx

http://technet.microsoft.com/en-us/sqlserver/ff686764.aspx

Answer 2

Vous ne l'avez pas mentionné exactement comment vous authentifier, mais peu importe, voici un script pour créer une connexion, des titres de compétence et de procuration et d'accorder des autorisations à SSIS paquets:

CREATE LOGIN [MyLogin] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english] 
GO 

GRANT CONNECT TO [MyLogin] 
go 

CREATE ROLE MyRole 
GO 

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole' 
GO 

CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyLogin', SECRET = 'MyPassword'; 

GO 

USE [msdb] 
GO 

EXEC msdb.dbo.sp_add_proxy @proxy_name=N'MyProxy',@credential_name=N'MyCredential', 
     @enabled=1 
GO 

EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name=N'MyProxy', @subsystem_id=11 
GO 

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'MyProxy', @login_name=N'MyLogin' 
GO 


CREATE ROLE MyRole 
GO 

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisadmin' 
GO 

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisoperator' 
GO 

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole' 
GO 

Answer 3

Juste travaillé à travers ce problème et est venu à une résolution différente. Une politique de sécurité globale entrait en conflit. Il s'avère que le serveur de développement qui présentait ce problème avait accidentellement une politique beaucoup plus restrictive que la contrepartie de production qui fonctionnait correctement. Vous ne savez pas exactement quelle permission outrepassée en vertu de la politique causait le problème, mais une politique moins restrictive a néanmoins résolu le problème. Fondamentalement, vérifiez auprès de votre administrateur Active Directory si la stratégie de sécurité locale est verrouillée sur le serveur présentant le problème.