David
Sat Jan 22 02:18:20 CST 2005
Permissions issue:
The identity used by IIS to execute ASP page (and hence your WshShell.Run
statement) depends on authentication used by client -- and that is
negotiated between the client and IIS in accordance to IIS authentication
settings and willingness of client. If anonymous authentication was used,
the identity would be the configured anonymous user account, which should be
IUSR_machinename by default. If other authentication was used, it should be
the remote user's logged in identity (or the login password dialog if
prompted).
Naming of the executable code:
Always use Absolute Pathname. Relative pathname invites PATH resolution and
unexpected behaviors because you are just making unjustified assumptions.
You can use Server.MapPath( "url" ) to dynamically determine the full
physical path of a given URL inside an ASP page -- i.e. it tells you that
"/" is mapped to "C:\inetpub\wwwroot" or "/vdir" is mapped to
"D:\data\websites\vdir" -- so you should never need to use relative pathname
to locate the application's physical directory. Server.MapPath is meant to
do this.
Location of the executable code:
If it is meant to be invoked directly by a URL, i.e.
http://localhost/vdir1/createOutputFile.exe , then it should be located in a
physical directory that has a virtual directory mapped to it and make sure
the directory allows "Scripts and Executables" execution permissions.
If it is NOT meant to be invoked directly by a URL, i.e.
http://localhost/vdir1/app.asp calls createOutputFile.exe to do work, then
you should locate it in a physical directory that DOES NOT have a virtual
directory mapped to it.
I believe that XP introduced some CMD.EXE security lockdown code such that
WshShell.Run from IIS doesn't work. Not certain if it is a factor here.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Warren Sirota" <wsirota@wsdesigns.com> wrote in message
news:ep63rB9$EHA.2012@TK2MSFTNGP15.phx.gbl...
Thanks for the info Ken. Filemon seems to show an Access Denied issue
with dllhost.exe:3460 when I try to open the asp page containing the
call to wshShell.run. I've tried making the IUSR account part of
Administrators, but that doesn't seem to fix the problem. Any ideas?
Even before we get to the permissions issue, is the question of where
should the file to be executed live and how should it be addressed. If
I just put an unqualified filename in the wshShell.run call (e.g.,
wshShell.run "createOutputFile.exe",,true) then I would expect (whether
correctly or incorrectly) that wshShell would attempt to run a copy of
the file in the same directory on the web site as the page that called
it. If I put in a qualified file name (e.g., wshShell.run
"C:\Windows\notepad.exe",,true), that doesn't seem to work either.
Should either of these work?
Thanks for any help you can offer.
Ken Schaefer wrote:
> Permissions problems can be troubleshooted using Filemon and Regmon
> from www.sysinternals.com
>
> Remember that unless you are using authentication, IIS will run ASP
> pages in the context of the configured "anonymous user account",
> which is IUSR_<machinename> by default.
>
> Cheers
> Ken
>
> "Warren Sirota" <wsirota@wsdesigns.com> wrote in message
> news:%23x5Ktpz$EHA.1264@TK2MSFTNGP12.phx.gbl...
> > Hi,
> >
> > I'm more of a programmer than an administrator, so please excuse me
> > if these questions are dumb. I've spent a couple of hours hunting
> > around for answers, to no avail.
> >
> > I'm running IIS 5.1 on my XP Pro development system. I'm trying to
> > shell out to an exe (in an ASP page) using code like:
> >
> > set wshShell = createobject("wscript.shell")
> > wshShell.run "C:\SomeFolder\createOutputFile.exe",,true
> >
> > where createOutputFile.exe is a VB (or perhaps some other kind) of
> > executable that takes a few seconds to create a report.
> >
> > I can run that code from VB, but I can't seem to get any variants
> > of it to run from asp - I always get the "application failed to
> > initialize" message. This is true whether I leave the full file
> > path in, or copy the executable to the web site and use either a
> > web address or an unqualified file path (i.e., either
> >
> > wshShell.run "//localhost/myWeb/createOutputFile.exe",,true
> >
> > or
> >
> > wshShell.run "createOutputFile.exe",,true
> >
> > I suspect a permissions problem, but I'm not sure how to deal with
> > it. Any suggestions? Thanks.
> >
> > Warren Sirota