SSIS包从文件系统调用报登录错误但部署至SSISDB运行正常，二者差异是什么？

你遇到的报错核心来自两种部署运行模式下，SSIS的敏感信息管理、身份上下文处理逻辑的差异，具体差异如下：

1. 敏感信息的存储与注入逻辑差异 #

• SSISDB部署运行场景：SSIS目录（SSISDB）内置了完整的参数、环境变量、连接管理器配置体系，即便你的包设置为不保存敏感信息，部署到SSISDB后可以在项目/包级别单独配置OLEDB连接的认证信息，运行时SSISDB会自动把合法的认证信息注入到连接管理器中，不需要依赖包文件本身存储敏感数据，也不会强制使用SQL Agent服务账户发起连接请求。
• 文件系统直接调用场景：包设置为不保存敏感信息时，所有连接的密码、身份上下文等敏感数据都不会存储在.dtsx包文件中，SQL Agent调用文件系统的包时没有SSISDB的配置注入能力，会直接读取包内的连接默认配置，用当前运行上下文的身份发起连接请求。

2. 运行时身份上下文的处理逻辑差异 #

• SSISDB部署运行场景：在SQL Agent中配置SSISDB包的作业步骤时，支持灵活配置执行身份：你可以选择用SQL Agent代理账户、SSIS目录指定的执行身份、或者包内置的模拟身份运行，Windows身份验证的连接会使用你指定的有权限的身份发起请求，默认不会直接使用SQL Agent服务账户SYS\SVC.SQL访问数据源。
• 文件系统直接调用场景：SQL Agent默认以自身服务账户SYS\SVC.SQL的身份启动DTExec.exe执行文件系统的SSIS包，如果你没有额外配置SQL Agent代理账户来运行该作业步骤，整个包的运行上下文完全绑定SYS\SVC.SQL的身份，所有OLEDB连接的Windows身份验证都会使用该账户发起请求，只要该账户没有对应数据源的访问权限，就会返回登录失败报错。

3. 部署模型的能力差异 #

• SSISDB部署默认使用项目部署模型，支持连接管理器、参数的项目级共享和集中配置，包运行时会优先读取SSISDB中存储的配置，覆盖包内的默认配置。
• 文件系统调用的包默认使用包部署模型，没有集中配置层，所有配置只能从包文件、环境变量、命令行参数中读取，没有SSISDB的配置覆盖能力。

内容的提问来源于stack exchange，提问作者Prefect73