根据你描述的情况，核心矛盾点在于SSIS包在命令行能正常执行，但通过网站调用就失败——这通常是因为两种执行方式的运行上下文差异导致的。结合你的环境配置，我给你几个针对性的排查方向：

1. 验证应用池身份的登录权限与配置文件初始化 #

虽然你说应用池用了和UAT相同的自定义用户，但生产环境的安全策略可能更严格：

• 先给这个自定义用户添加允许本地登录和作为批处理作业登录的权限（在本地安全策略的「用户权限分配」里设置）
• 另外，非交互式会话的用户配置文件可能未初始化，你可以手动用该用户登录一次生产服务器，执行一遍dtexec命令，再测试网站调用——这一步能帮用户创建完整的配置文件，避免后续访问资源时出错

2. 检查DCOM配置中的SSIS服务权限 #

网站调用SSIS包会涉及DCOM通信，生产环境的DCOM权限可能和测试/UAT不一致：

• 打开dcomcnfg，导航到组件服务 → 计算机 → 我的电脑 → DCOM配置
• 找到「Microsoft SQL Server Integration Services 12.0」（对应SQL Server 2014），右键选择属性
• 在安全选项卡：
  • 确保自定义应用池用户在「启动和激活权限」里有本地启动和本地激活权限
  • 在「访问权限」里有本地访问权限
• 切换到标识选项卡，确认设置为「交互式用户」或者直接指定你的自定义用户（如果之前是其他设置的话）

3. 确认Excel文件的实际访问路径 #

有时候网站调用时，相对路径或者IIS工作目录会导致文件路径和预期不符：

• 在你的C#代码里，把实际访问的Excel文件绝对路径输出到日志（比如用System.IO.Path.GetFullPath()获取），核对和命令行执行时的路径是否完全一致
• 检查IIS应用池的加载用户配置文件选项是否开启（应用池高级设置里），设为True。如果关闭的话，用户的临时目录会用系统临时目录，可能触发权限问题

4. 确保32位Ace驱动与IIS进程位数匹配 #

你已经禁用了SSIS的64位运行，但还要确认网站进程是32位的：

• 把网站应用池的启用32位应用程序设为True（高级设置里），因为你用的是32位AceODBC驱动，只有32位进程才能正确加载它
• 另外，检查生产服务器是否同时装了64位的Ace驱动，混合安装很容易导致冲突，建议卸载64位版本，只保留32位的Access 2013运行时和Ace驱动

5. 启用SSIS详细日志定位具体错误 #

默认的报错信息太笼统，你可以给SSIS包加详细日志：

• 打开SSIS包，添加SQL Server或文本文件日志提供程序
• 勾选OnError、OnPreExecute、OnInformation这些关键事件
• 然后通过网站调用执行包，查看日志的详细输出，就能找到预执行阶段具体卡在哪里

6. 检查临时目录的特殊权限 #

除了常规读写权限，还要确认自定义用户对以下目录有完全控制权限：

• 用户临时目录：C:\Users\[自定义用户名]\AppData\Local\Temp
• 系统临时目录：C:\Windows\Temp
• SSIS运行时临时目录：C:\Program Files\Microsoft SQL Server\120\DTS\Temp（对应SQL2014）

另外，你可以试试把Excel文件复制到本地磁盘的非上传目录再执行包，排除Azure存储或上传目录的特殊限制。

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