我有一个 SSIS 作业,它从 SharePoint 2010 列表中获取数据,该列表可以从 Visual Studio 完美运行,而且如果我从 SSIS 存储手动触发它,但在 SQL Server 数据库引擎实例中安排为作业时则不会。
我只使用一个名为“spadmin”的超级用户帐户来做所有事情。
- 这是我用来登录 Windows 7 工作站的帐户,我从中设计了 SSIS 程序包,并且我倾向于运行 SSMS。
- 是用于登录 SQL Server 并对本地服务器和 SQL(所有内容)具有完全管理权限的帐户。
- 我在 SSIS 包中使用的也是该用户的凭据,以连接到我需要的一切。
- 它也是指定运行计划作业的帐户。
如果我通过 SQL Server Management Studio (SSMS) 连接到 SQL Server 的 SSIS 存储(而不是数据库引擎),然后右键单击存储在“Stored Packages\MSDB”下的相关作业并选择执行它,作业将运行没有任何问题。无论我是使用安装在相关 SQL Server 上的本地 SSMS,还是使用远程工作站上的 SSMS 安装,都会发生这种情况。
但是,如果我通过同一个 SQL 的服务器数据库引擎安排作业,则作业将失败 - 无论是按计划还是尝试手动运行作业。
现在这是令人费解的一点:如果我在后台使用超级用户帐户(即 spadmin)与 SQL Server 建立远程桌面连接,则该作业不会失败,同时我运行该作业。在后台,我的意思是除了使用超级用户帐户登录外,我没有在此远程桌面连接上做任何事情。
当作业失败时,我收到以下“Bad Gateway”错误(请参阅帖子末尾),表明问题出在访问 SharePoint 上。但是,由于我可以使用与计划作业相同的帐户通过 SSIS 存储运行此作业,因此毫无疑问,此作业能够从 SQL Server 运行。
服务器构建:10.50.1617
我要在这里精神。关于问题可能是什么的任何想法?
为了完整起见,这里是完整的错误消息:
消息以用户身份执行:MYDOMAIN\spadmin。...n 10.50.1600.1 适用于 64 位 版权所有 (C) Microsoft Corporation 2010。保留所有权利。开始时间:13:19:34 错误:2017-01-27 13:19:34.76 代码:0xC0047062 来源:复制共享点列表数据 SharePoint 列表源 [1]
说明:System.ServiceModel.ProtocolException:远程服务器返回意外响应:(502) Bad Gateway。---> System.Net.WebException:远程服务器返回错误:(502)错误网关。在 System.Net.HttpWebRequest.GetResponse() 在 System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) --- 内部异常堆栈跟踪结束 --- 服务器堆栈跟踪:在 System.ServiceModel.Channels .HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest 请求,HttpWebResponse 响应,HttpChannelFactory 工厂,WebException responseException,ChannelBinding channelBinding)在 System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply)(TimeSpan 超时)。
说明:组件“SharePoint List Source”(1) 验证失败并返回错误代码 0x80131501。结束错误错误:2017-01-27 13:19:34.76 代码:0xC004700C 来源:复制共享点列表数据 SSIS.Pipeline 描述:一个或多个组件验证失败。结束错误错误:2017-01-27 13:19:34.76 代码:0xC0024107 来源:复制共享点列表数据描述:任务验证期间出现错误。结束错误 DTExec:程序包执行返回 DTSER_FAILURE (1)。S... 程序包执行失败... 该步骤失败。
这是答案。
即使该作业配置为通过代理帐户运行,SQL Server 代理仍然负责该作业。我看了一下 SQL Server 代理被配置为在该服务器上的本地系统帐户下运行。所以我所做的是让代理在超级用户管理员帐户下运行并且它按预期工作。
现在在这种情况下,作业不再需要代理,因为服务器代理本身在最终帐户下运行。但是,我明白这不是前进的正确方式(即使这不是我的服务器,我希望我再也不会碰它了!)我会建议客户重新配置 SQL,以便每项服务都在专用域下运行帐户(即专为此目的创建),这是应该的方式!
现在我想知道的是,为什么只要用于安排作业的代理帐户登录到 SQL 服务器,作业就会运行!