Your problem might be in using .run rather than .Exec.
You may not need to user Server.CreateObject since it is already executing in the servers context, though it may not make any difference.
Your second code relies on ASPExec being installed.
Remember also that the IUSR_machinename account will have to have execute permission on the bat file wherever it resides. And depending on what you are executing, the local machine ID may have to have permissions as well.
We just used a similar script to the one below for firing off a batch file to execute events on the database server so I know it works. The batch file executes based on the IUSR account but the program for firing events in the database requires that the computer itself have permission set in the database.
This code works.
Code:
Response.Buffer = true
Set objWShell = CreateObject("WScript.Shell")
Set objCmd = objWShell.Exec("c:\test.bat")
strPResult = objCmd.StdOut.Readall()
set objCmd = nothing: Set objWShell = nothing
response.write strPResult
It executes the batch file and sends the response back to the screen.
Also, I have had problems with folder and filenames greater than 8 characters when executing with the Shell object so you have to truncate any long names to the 8.3 convention.
For instance: C:\Documents and Settings\myfile.bat
would have to be done as: C:\Docume~1\myfile.bat
You replace the long name with the first six characters, a tilde and a numerical reference.
The numerical reference is based on the alphabetic position of the name in the folder.
For instance if you have a folder "Documents and Settings"
and a folder "Documents of Mine" both would begin with Docume~ but the number would depend on which one comes first alphabetically.
Documents and Settings come before Documents of Mine alphabetically so Documents and Settings = Docume~1 and Documents of Mine = Docume~2.
Paranoid? ME?? WHO WANTS TO KNOW????