Ошибка прокси-сервера при выполнении службы SSIS через агента

Question

Недавно, когда я создал задание агента SQL Server (2008) для выполнения пакета SSIS с учетной записью прокси-сервера, оно не удалось с приведенным ниже сообщением об ошибке. О чем это исключение? Что вызывает его и как его разрешить?

Сообщение об ошибке Выполнено как пользователем: blaw. Процесс не может быть создан для шага 1 задания 0xD5A5 (причина: требуемая привилегия не удерживается клиентом). Не удалось выполнить этот шаг.

Примечание: -Это отлично работает с учетной записью агента агента.

Благодаря

Answer 1

Я пытаюсь получить эту работу прямо сейчас, как хорошо. Вы пытаетесь взглянуть на эти ресурсы?

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

Вы не упомянули, как именно вы аутентичности, но независимо от того, вот скрипт для создания входа, учетных и прокси и предоставления разрешений SSIS пакеты:

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

Только что прошел через эту проблему и пришел к другой резолюции. Глобальная политика безопасности мешала. Оказывается, сервер разработки, который представлял эту проблему случайно, применял гораздо более ограничительную политику, чем работающий коллега, который работал нормально. Не совсем уверен, что переопределенное разрешение в рамках этой политики вызывало проблему, но менее жесткая политика разрешала проблему тем не менее. В основном, обратитесь к администратору Active Directory, если локальная политика безопасности заблокирована на сервере, представляющем проблему.