IIS6 and ASPExec

You could set a file level audit for your batch to see when it was last exe'd.
Also, make sure you have IIS setup correctly. Out of the box, or default install IIS 6.0 is pretty stipped down.

juststeve - what is it that your batch file is trying to achieve exactly, most of the time it is easier to re-engineer a process than trying to layer a wrapper like this

You could also try something like this:

<%
set oWS=server.createobject("WScript.shell")
ret=oWS.Run("X:\my.bat", 2, true)

if(ret=0) then
response.write("it is working<br>")
else
response.write("not working<br>")
end if
%>

I guess i need step by steps in the 'set file level audit' and what to watch for....I've tried a couple things but so far that hasn't made a lot of sense.

The batch runs LogPrep.exe (massages the contents of the server log file into a db-importable format) and fires a stored procedure that imports it to my db.

Currently I maintain a Terminal Services connection to run it from a command window everything i want to update the db-logs (frequently). I'd like to eliminate the need for TS by firing the batch from a hit to a web page.

Typically that'd be ok...right now I'm actively troubleshooting/debugging and want immediate feedback after I made a file change.

WHat might be a good idea then is to se the WScript calls that af500 suggests, and have that batch file right out some sort of report to a text file ( no need with fancy html of xml) and that should report back to you enough info

One thing to look for is that your batch file uses explicits. ... so even if the .bat is in the same folder as your .exe or whatever your executing use the full path to it. Also, make sure your user has executable privs.

af500's code returns 'not working'. i tested this with both IUSR & IWAM accounts inside the administrator's group. I also tested against a batch file that just does a 'dir' to see if the problem related to writing a file. no joy.

Yep...I'm using full path to all files. I've edited the setting on cmd.exe to allow IUSR access.

Have you registered the DLL? If not do it from the cmd with regsvr32.

Alternatively, and to make it easier in future to reg and unreg DLL's, go to your registry editor, navigate to (HKEY_CLASSES_ROOT\dllfile) and add Key: RegSvr32, inside it another Key: Command, and inside Command change the Default value to: "regsvr32.exe %1", make sure you enclose it with "", now you can reg/unreg from the Windows Explorer, the options for it will be avalable on right-click over DLL's.

Quote "The batch runs LogPrep.exe"

No dll's invovled

Just some corrections to my reg/unreg approach:

Go to your registry editor, navigate to (HKEY_CLASSES_ROOT\dllfile) and add Key: RegSvr32, inside it another Key: Command, and inside Command change the Default value to: regsvr32 "%1"

To UnReg do the same but call it UnRegSvr32 > Command > Default with value of: regsvr32 -u "%1", now you can reg/unreg from the Windows Explorer, the options for it will be avalable on right-click on DLL's.

Hope this helps.

What is the error??!!

Good thinking but alas, err.description is blank:

not working
The Error Is:
0--

i tried using err.source with same no result.

What does "response.write ret" give you ?

1

Provided you have the permissions correct and that you have scripts and execute permissions set in IIS (I am not 100% sure that execute is truley needed) then it may point to the WScript component itself. All to often we tend to assume it is our code and not MS - see if you can find an update http://www.microsoft.com/scripting

No real resolution to my problem here but I have to move on. Extreme thankx to af500 for the help as well...i meant to split points out to you but clicked wrong. I'll post a change request to community support.

One possible solution is changing your IIS Application Pool setting. You can try to set the identity to Local System which is default identity for previous version of IIS.

Hi Steve,

I'm not sure whether you get email notifiers on older stuff or not, so I  thought I'd post here as well.  I think the main problem was that IIS Admin needed to interact with the desktop as well, although I may be wrong, as I did do quite a lot of things quite late at night..

I've had exactly the same problems with ASPEXEC on a new install of WinXP Pro. After burning the midnight oil, and tearing out most of my hair, I managed to get it working..

Thought I'd post a note with the things I did to fix it, in case any of these are useful to anyone.

checked 'Allow service to interact with desktop' for IIS Admin as well as WWW svcs
allowed IUSR_****** read access to cmd.exe and read/execute to target directory
turned _off_ script blocking in Norton AV 2003...

didn't need scripts and executables turned on, only scripts.

I need to set it up on a 2003 server tomorrow myself, so will see..

Tiff