Jump to content

Runwait Working In 2000 But Not Xp


Recommended Posts

I have a command in a script that works on W2K PC's but not on XP Pc's

The command is

Runwait("t:\VP_Log32.exe /p=T:")

Runs well on W2k pc's but on XP PC's get the

Error: unable to execute the external program. The system cannot find the the file specified.

Any ideas???

this is what the entire bat file looks like

@SET LANG=ENU

@SET FILE_SERVER=xxxxx

@ECHO OFF

REM *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

REM

REM VPLOGIN.BAT

REM Description: Client login script file for Windows NT Servers running

REM Norton AntiVirus Corporate Edition

REM

REM *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

rem %0\..\NBPSHPOP +T: \\%FILE_SERVER%\vplogon

if "%OS%" == "Windows_NT" goto WINNT_NBPSHPOP

%0\..\NBPSHPOP +T: \\%FILE_SERVER%\vplogon

goto MOVEON

:WINNT_NBPSHPOP

NBPSHPOP +T: \\%FILE_SERVER%\vplogon

:MOVEON

T:\OSVER

IF ERRORLEVEL 2 GOTO WIN_32

REM *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

:WIN_32

pass.exe

rem T:\VP_Log32 /p=T:

GOTO END

REM =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

:END

rem %0\..\NBPSHPOP -T:

if "%OS%" == "Windows_NT" goto WINNT_NBPSHPOP_END

%0\..\NBPSHPOP -T:

goto MOVEON_END

:WINNT_NBPSHPOP_END

NBPSHPOP -T:

:MOVEON_END

goto quit

the pass.exe is the script, it looks like this

RunAsSet("xxxxx", "xxxxx", "xxxxx")

Runwait("t:\VP_Log32.exe /p=T:")

Again it works in 2000 but no on xp

Thanks in advance.

Link to comment
Share on other sites

if the runasset is a local account and T:'s access is set on a domain/AD/"something besides that local name" then there's going to be problems... the way I avoid that is to do a fileinstall or filecopy of the exe to a local drive before the runasset

should this be in the FAQ? I mean, I asked it, he's asked it, other people ask it...

Edited by emmanuel

"I'm not even supposed to be here today!" -Dante (Hicks)

Link to comment
Share on other sites

if the runasset is a local account and T:'s access is set on a domain/AD/"something besides that local name" then there's going to be problems...  the way I avoid that is to do a fileinstall or filecopy of the exe to a local drive before the runasset

should this be in the FAQ?  I mean, I asked it, he's asked it, other people ask it...

It is not a local acount, it is a domain account
Link to comment
Share on other sites

It is not a local acount, it is a domain account

drat, foiled again. maybe do something to check that you can see that location, and if not, remap the drive or something? like

if fileexists("T:\VP_Log32.exe") == 0 then

;do something like map the drive or somesuch?

endif

or, maybe just try single quotes instead of double quotes? guessing here.. . it works to manually run that exe with those switches on the xp machines, logged in as that account, right?

"I'm not even supposed to be here today!" -Dante (Hicks)

Link to comment
Share on other sites

drat, foiled again.  maybe do something to check that you can see that location, and if not, remap the drive or something?  like

if fileexists("T:\VP_Log32.exe") == 0 then

;do something like map the drive or somesuch?

endif

or, maybe just try single quotes instead of double quotes?  guessing here.. . it works to manually run that exe with those switches on the xp machines, logged in as that account, right?

I tried the fileexists function, and that worked fined.

I did a test with notepad on the c: and on the f:drive

This worked

Runwait("notepad.exe", "c:\")

but this did not (notepad.exe was copied to f:)

Runwait("notepad.exe", "f:\")

almost like it won't run anything off a drive other than c:

is that correct?

Link to comment
Share on other sites

I tried the fileexists function, and that worked fined.

I did a test with notepad on the c: and on the f:drive

This worked

Runwait("notepad.exe", "c:\")

but this did not (notepad.exe was copied to f:)

Runwait("notepad.exe", "f:\")

almost like it won't run anything off a drive other than c:

is that correct?

the working dir isn't the path to the exe, it's the dir the app will use as it's working dir, or that's my understanding anyways. I run stuff from other drives or unc network shares all the time.

Runwait("f:\notepad.exe", "f:\")

and

Runwait("f:\notepad.exe")

would both do the same thing.

"I'm not even supposed to be here today!" -Dante (Hicks)

Link to comment
Share on other sites

an alternate solution is to loop until that EXE is no longer in memory, possiblly like this:

Runwait("t:\VP_Log32.exe /p=T:")
while ProcessExists ( "VP_Log32.exe" ) 
sleep(10)
wend

does that Exe show up in task manager?

AutoIt3, the MACGYVER Pocket Knife for computers.

Link to comment
Share on other sites

the working dir isn't the path to the exe, it's the dir the app will use as it's working dir, or that's my understanding anyways.  I run stuff from other drives or unc network shares all the time. 

Runwait("f:\notepad.exe", "f:\")

and

Runwait("f:\notepad.exe")

would both do the same thing.

but does it work on XP?

i copied notepad up to a network drive.

Ran it from w2k, no prob, xp prob

Edited by pcuevas
Link to comment
Share on other sites

an alternate solution is to loop until that EXE is no longer in memory, possiblly like this:

Runwait("t:\VP_Log32.exe /p=T:")
while ProcessExists ( "VP_Log32.exe" ) 
sleep(10)
wend

does that Exe show up in task manager?

see their first post:

Error: unable to execute the external program. The system cannot find the the file specified.

"I'm not even supposed to be here today!" -Dante (Hicks)

Link to comment
Share on other sites

oops, I was thinking it was the runwait part. :D

Just to clarify, you are absolutly sure that that account works on both machines?  Can you log into the winXP macine with those credentials?

this is where I'm thinking the problem might lay as well, btw...

"I'm not even supposed to be here today!" -Dante (Hicks)

Link to comment
Share on other sites

I am having the same problem. In fact, I was looking for a solution when I stumbled upon this thread.

I can do something as simple as...

RunAsSet("Admin", @LogonDomain, "Password")

RunWait(@comspec)

...and it won't work if I am running it on a mapped drive. If I copy the script to my local drive then it works fine.

Edit: I'm using Windows XP. On another thread, I read that Windows 2000 seems to be working fine, but I haven't tried it on a Win2K machine yet.

Edited by SerialKiller
Link to comment
Share on other sites

oops, I was thinking it was the runwait part. :D

Just to clarify, you are absolutly sure that that account works on both machines?  Can you log into the winXP macine with those credentials?

Yes the credentials both work on 2000 and XP.

This is an 4.0 domain not AD, if this makes a difference.

again

this works on on 2000

Runwait("f:\notepad.exe") and Runwait("c:\notepad.exe")

but on xp this works Runwait("c:\notepad.exe")

but this does not Runwait("f:\notepad.exe")

Link to comment
Share on other sites

I've seen this problem before. I had an AI script that uses RunAsSet() and RunWait() and uses domain id (4.0 domain) and works on 2000 but not on XP. The RunWait() runs an executable on a network drive. I think it has something to do with the credential implementation on XP. My workaround was to bundle the executable in the script using FileInstall() and put it on the local machine and run it from there. I think the FileExist() works because it uses the current user credentials and not the authenticated user credentials (I might be wrong though).

Hope this help!

-MX-

Link to comment
Share on other sites

  • 7 months later...

but on xp this works Runwait("c:\notepad.exe")

but this does not Runwait("f:\notepad.exe")

<{POST_SNAPBACK}>

Same Problems i found - using mapped drives and/or running parts with local admin account (to get necessary rights).

The solution was to define a LOCAL workingdir as a text string like "c:\temp". Variables like @UserProfilrDir, @Homedrive and @HomePath didn't work for me.

Wolfgang Führer

Link to comment
Share on other sites

  • 1 year later...

Just an info for all of you who ran into this issue -- I got it resolved by commenting out the RunAsSet statement.

The Run() and RunWait() works now however you lose the capability of running the executable under a different credential than the logged on user. For us it's not that big an issue as we use SMS as the distribution tool and it allows for running the executable under a different set of security context which achieves the same as RunAsSet.

My 2 cents

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...