IIS 可执行文件未执行
我已经连续一周关注一个问题，但一直无法解决它，我迫切想要修复。
在客户站点上，我们有两个环境：UAT 和 PROD。 UAT 工作完美（请记住这一点）。我们现在正在尝试将解决方案部署到 PROD，但解决方案的某些部分无法正常工作。
我们开发了一个 asp.net 应用程序，提供给客户以允许他们调用 SSIS 包（他们首先选择几个下拉列表，然后单击名为“invoke”的按钮）。 当用户单击 Invoke 按钮时，将调用名为 InvokeSSIS.bat 的批处理文件，该文件使用适当的参数组装对 dtexec 的命令行调用。
我遇到了一个特定包的问题，该包负责调用一个可执行文件，该可执行文件生成一个我将导入到我的系统中的电子表格。
可执行文件位于映射的 H:\ 驱动器上。
我已修改 InvokeSSIS.bat 批处理文件以捕获批处理文件生成的命令。如果我从命令行执行此命令，它会完美运行。从 webapp Invoker 中，它执行包，但负责调用可执行文件的任务不会执行，因为整个包只需要 1 秒即可完成（而应该需要大约一分钟）。
可执行文件确实有一个 GUI，但它不是交互式的。这是因为当您使用特定参数调用 GUI 时，它会自动以批处理模式运行并执行用于生成所需电子表格的宏。
我知道这没问题，因为它可以在 UAT 服务器上运行并且可以从命令行运行！
我已检查可执行文件的权限（右键单击可执行文件并单击属性。）我已将可执行文件的完全控制权限授予指定为我正在使用的应用程序池的身份选项卡的同一用户。
有人可以帮我吗？正如我所说，我快死在这里了！
如果您有任何想法或需要其他信息，请告诉我。
环境（UAT 和 PROD） 操作系统：Windows Server 2003
IIS 6
ASP.NET 2.0
SQL Server 2008
谢谢！
史蒂夫
I have been looking at an issue for a week straight and have been unable to figure it out and I am desperate for the fix.
On a client site, we have two environments: UAT and PROD. UAT works perfect (Please keep this in mind). We are now trying to deploy the solution to PROD but certain parts of the solution are not working.
We have developed an asp.net application that we provide to clients to allow them to invoke SSIS packages (there are a couple of drop downs that they first select then click a button named "invoke").
When the user clicks the Invoke button, a batch file named InvokeSSIS.bat is called that assembles a command line call to dtexec with the appropriate parameters.
I'm having a problem with a particular package that is responsible for calling an executable which generates a spreadsheet that i will be importing into my system.
The executable is on an mapped H:\ drive.
I have modified the InvokeSSIS.bat batch file to capture the command the batch file is generating. If I execute this command from the command line, it works perfectly. From the webapp Invoker, it executes the package but the tasks responsible for calling the executable doesn't execute as the entire package takes only 1 second to complete (whereas it should take about a minute.)
The executable DOES have a GUI, but it is NOT interactive. This is because when you call the GUI with specific parameters, it automatically runs in batch mode and executes a macro used to generate the desired spreadsheet.
I know this is ok because it works on the UAT server AND it works from the command line!
I have checked the permissions on the executable (bu right-clicking the executable and clicking properties.) I have granted Full Control on the executable to the same user specified as the identity tab of the application pool i am using.
Can someone please help me? As I said I am dying over here!
Please let me know if you have any ideas or what other info you need.
Environment (both UAT and PROD)
OS: Windows Server 2003
IIS 6
asp.net 2.0
SQL Server 2008
Thanks!
Steve
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能将映射驱动器与 IIS 一起使用。
您必须使用 \\servername 语法来访问其他系统上的文件。
You can't use a mapped drive with IIS.
You must use the \\servername syntax to reach files on other systems.
我同意 user544284 的观点，这至少部分是一个映射问题。我将暂时忽略让 Web 应用程序调用批处理文件以通过驱动器盘符映射启动远程网络驱动器上的可执行文件的完全疯狂。
最有可能的是，UAT 盒已设置了某些内容，可以映射您的产品缺少的驱动器盘符。
唯一的另一种可能性是发生安全违规。从网络驱动器运行 .exe 通常是不受欢迎的。两个环境的windows版本是否完全相同？它们的 UAC 配置是否相同？这里的任何差异都很重要。
这带来了一个有趣的想法。我想知道是否有人使用应用程序池使用的相同帐户凭据登录到 UAT 服务器，并将 exe 所在计算机的 IP 地址添加到“本地 Intranet”站点列表中...或者，如果他们安装了 SSIS在 UAT 服务器本身上。
仅仅因为您可以登录服务器并在命令行上运行它没有任何意义。您必须查明驱动器号是否已映射到运行 Web 应用程序的用户，以及该用户是否具有所需的安全位，以及本地操作系统是否允许这样做。
好吧，我不能忽视它：“hairbrained”是我能为这个“架构”想到的最好的形容词。帮自己一个忙，重新开始这件事。正如您已经发现的那样，它上面写满了“易碎”一词。无需构建批处理文件来调用 dtexec，只需通过类似 此 或 这个。
I agree with user544284 that this is at least in part a mapping issue. I'll ignore for a minute the complete insanity of having a web application call a batch file to start an executable that's on a remote network drive through a drive letter mapping.
Most likely the UAT box has something set up that maps that drive letter for you which Prod is missing.
The only other possibility is a security violation is occurring. Running .exe's from a network drive is generally frowned on. Do the two environments have the exact same version of windows? Are they configured the same with regards to UAC? Any differences here are going to be important.
Which brings up an interesting thought. I wonder if someone logged in to the UAT server using the same account credentials the app pool is using and added the ip address of the machine where the exe lives to the list of "Local Intranet" sites... Or, if they installed SSIS on the UAT server itself.
Just because YOU can log in to the server and run it on the command line means nothing. You have to find out if the drive letter is mapped at all for the user that the web app is running under and whether that user has the required security bits and whether the local OS will allow it regardless.
Okay, I can't ignore it: hairbrained is the nicest adjective I can come up with for this "architecture". Do yourself a favor and go back to the drawing board on this one. It has the word "brittle" written all over it, as you have already found. Instead of building out a batch file to call dtexec, just do it directly either by something like this or this.