Run VBS on a Remote?

[RayportingMonkey]

My basic scenario is that I have a laptop that I do "light work" from and a
power-house desktop that I develop and run automated reports on. Currently, I
have a series of VBS files that download source data from a web location to a
local/working directory on my Desktop.

Some of these files can get pretty large.

The problem is that I receive notification on my laptop via Outlook that the
data is available and had set a rule in Outlook to run the applicable script,
which reside on my desktop.

I want to run the script from the (remote) desktop and not from my laptop.

Do I need to setup a service on the desktop in Windows XP or something to do
this? Or is there a way to specify the name of the machine on which a script
should run?

This is a new approach for me, so I may not be communicating as clearly as I
could - if clarification is required, let me know. I apprecaite a point in
the right direction!

Thanks,
Ray

 

[3c273]

You can use PSExec from Sysinternals to run the script on the remote
machine. It is available on the MS website.
Louis

 

[Pegasus \(MVP\)]

My basic scenario is that I have a laptop that I do "light work" from and
a
power-house desktop that I develop and run automated reports on.
Currently, I
have a series of VBS files that download source data from a web location
to a
local/working directory on my Desktop.

Some of these files can get pretty large.

The problem is that I receive notification on my laptop via Outlook that
the
data is available and had set a rule in Outlook to run the applicable
script,
which reside on my desktop.

I want to run the script from the (remote) desktop and not from my laptop.

Do I need to setup a service on the desktop in Windows XP or something to
do
this? Or is there a way to specify the name of the machine on which a
script
should run?

This is a new approach for me, so I may not be communicating as clearly as
I
could - if clarification is required, let me know. I apprecaite a point in
the right direction!

Thanks,
Ray

If the desktop runs Windows Professional then Remote Desktop
may be another option. It would give you complete control over
the desktop in a GUI environment.

 

[RayportingMonkey]

If the desktop runs Windows Professional then Remote Desktop

may be another option. It would give you complete control over
the desktop in a GUI environment.

Agreed - Except I am attempting to automate the process. So opening a remote
session and launching the script is precisely what I am trying to avoid.

I need to be able to run the script on the remote PC, but I can only seem to
run the process that resides on the remote PC locally - negating the speed
and power of the remote PC.

 

[RayportingMonkey]

You can use PSExec from Sysinternals to run the script on the remote

machine. It is available on the MS website.

I downloaded and installed PSExec and can make it do simple things, like run
a DIR on the remote and such, but when I attempt to execute something like:

psexec \\MyDesktopsName C:\WorkingDirectory\FileName.vbs

PsExec launches and tells me, "The system cannot find the file specified".

I can see that there is an instance of wscript.exe running on the remote
machine, but there is a "beep" and no further information.

Again, these are production scripts that work when run locally, but seem to
just hang when I attempt to run them via PsExec.

 

[Pegasus \(MVP\)]

I downloaded and installed PSExec and can make it do simple things, like
run
a DIR on the remote and such, but when I attempt to execute something
like:

psexec \\MyDesktopsName C:\WorkingDirectory\FileName.vbs

PsExec launches and tells me, "The system cannot find the file specified".

I can see that there is an instance of wscript.exe running on the remote
machine, but there is a "beep" and no further information.

Again, these are production scripts that work when run locally, but seem
to
just hang when I attempt to run them via PsExec.

You should not rely on the remote machine "knowing" what to do with
a .vbs file - when automating a process you should always be explicit
and invoke the underlying executable in order to make it robust:

psexec \\MyDesktopsName cscript.exe //nologo
C:\WorkingDirectory\FileName.vbs

 

[RayportingMonkey]

You should not rely on the remote machine "knowing" what to do with

a .vbs file - when automating a process you should always be explicit
and invoke the underlying executable in order to make it robust:

psexec \\MyDesktopsName cscript.exe //nologo
C:\WorkingDirectory\FileName.vbs

OK - Getting a little further I think, but not there yet...

When I run that I get an error that reads:

C:\WorkingDirectory\FileName.vbs(7,1) msxml3.dll: Access is denied.

I am an admin on both boxes, am logged into both with the same credentials
and even tried the -u / -p switches just in case, but to no avail.

Thanks for your help thus far.

 

[Pegasus \(MVP\)]

OK - Getting a little further I think, but not there yet...

When I run that I get an error that reads:

C:\WorkingDirectory\FileName.vbs(7,1) msxml3.dll: Access is denied.

I am an admin on both boxes, am logged into both with the same credentials
and even tried the -u / -p switches just in case, but to no avail.

Thanks for your help thus far.

Can't tell - my scripts run perfectly well under psexec.exe. You
need to examine the specific permissions of msxml3.dll.

To prove the principle you should really start the exercise with
a very basic script file, e.g. by putting the following two lines of
code right on top of your script, before any other code:

wscript.echo "Hello world"
wscript.quit

You must also remember that psexec.exe does not support
any GUIs. It's console stuff only.

 

[3c273]

It looks like vbs files won't run directly and I see you've tried this but
this command works on my setup.
psexec -i \\machinename cscript "c:\path\test.vbs"
Louis

 

[RayportingMonkey]

It looks like vbs files won't run directly and I see you've tried this but

this command works on my setup.
psexec -i \\machinename cscript "c:\path\test.vbs"

Yeah... I can run simple scripts (i.e. "Hello World"), so I guess you could
say that PsExec is "working", but the scripts I need to run fail when
executed via PsExec.

 

[RayportingMonkey]

To prove the principle you should really start the exercise with

a very basic script file, e.g. by putting the following two lines of
code right on top of your script, before any other code:

wscript.echo "Hello world"
wscript.quit

You must also remember that psexec.exe does not support
any GUIs. It's console stuff only.

Just to test, I setup a sample script with just those two lines and yes, it
runs as expected, so I guess you could say that PsExec is "working".

But that still doesn't benefit me as the scripts I need to run are giving me
the same error: C:\WorkingDirectory\FileName.vbs(7,1) msxml3.dll: Access is
denied

I tried looking around online and could't find anyting specific to the
"(7,1)" identifier in the "msxml3.dll: Access is denied" message. There were
security/trust references to IE, but my scripts stream their files without
opening IE.

Some related references to this error message did refer to XML and there are
XML calls in my script, so I am starting to wonder if that's related...

I am pasting a copy of my script here for reference :

FileName = "Dispatches 2008.xls"
DestFolder = "\\MyComputerName\Share\"
URL = "http://serverURL/Document Library/Dispatches 2008.xls"

Set xml = CreateObject("Microsoft.XMLHTTP")
xml.Open "GET", URL, False
xml.Send

set oStream = createobject("Adodb.Stream")
Const adTypeBinary = 1
Const adSaveCreateOverWrite = 2
Const adSaveCreateNotExist = 1

oStream.type = adTypeBinary
oStream.open
oStream.write xml.responseBody

oStream.savetofile DestFolder & FileName, adSaveCreateOverWrite

oStream.close

set oStream = nothing
Set xml = Nothing


Again, this thread has seemed to focus on the use of psexec, but if there is
another method I should try (TSR, some sort of custom Windows Service,
etc...) I am open to exploring.

For me, this is primarially a bandwidth issue. I don't want to be
downloading 10-50MB data source files to my laptop (over shi**y 802.11b
wireless) in my home office, only to have to copy them over a VPN to my
office desktop where the downloaded files and the scripts that grab them
reside in the first place - especially when some of the larger files come
from my intranet, so access from my desktop sucks down those packets fast!

Thanks for the help thus far - Any additional help is greatly appreciated!

Regards,
Ray

 

[Pegasus \(MVP\)]

Just to test, I setup a sample script with just those two lines and yes,
it
runs as expected, so I guess you could say that PsExec is "working".

But that still doesn't benefit me as the scripts I need to run are giving
me
the same error: C:\WorkingDirectory\FileName.vbs(7,1) msxml3.dll: Access
is
denied

I tried looking around online and could't find anyting specific to the
"(7,1)" identifier in the "msxml3.dll: Access is denied" message. There
were
security/trust references to IE, but my scripts stream their files without
opening IE.

Some related references to this error message did refer to XML and there
are
XML calls in my script, so I am starting to wonder if that's related...

I am pasting a copy of my script here for reference :

FileName = "Dispatches 2008.xls"
DestFolder = "\\MyComputerName\Share\"
URL = "http://serverURL/Document Library/Dispatches 2008.xls"

Set xml = CreateObject("Microsoft.XMLHTTP")
xml.Open "GET", URL, False
xml.Send

set oStream = createobject("Adodb.Stream")
Const adTypeBinary = 1
Const adSaveCreateOverWrite = 2
Const adSaveCreateNotExist = 1

oStream.type = adTypeBinary
oStream.open
oStream.write xml.responseBody

oStream.savetofile DestFolder & FileName, adSaveCreateOverWrite

oStream.close

set oStream = nothing
Set xml = Nothing


Again, this thread has seemed to focus on the use of psexec, but if there
is
another method I should try (TSR, some sort of custom Windows Service,
etc...) I am open to exploring.

For me, this is primarially a bandwidth issue. I don't want to be
downloading 10-50MB data source files to my laptop (over shi**y 802.11b
wireless) in my home office, only to have to copy them over a VPN to my
office desktop where the downloaded files and the scripts that grab them
reside in the first place - especially when some of the larger files come
from my intranet, so access from my desktop sucks down those packets fast!

Thanks for the help thus far - Any additional help is greatly appreciated!

Regards,
Ray

Sorry, I've almost run out of ideas. Here is what I would do:
- Start a console session on the host (by sitting in front of it), using a
Domain Administrator account, then execute the command
cscript //nologo C:\WorkingDirectory\FileName.vbs
- Start a Command Prompt on the host with psexec.exe (while
sitting in front of your laptop), then run the script:
psexec \\YourHost -u DomainName\DomainAdmin cmd{Enter}
cscript //nologo C:\WorkingDirectory\FileName.vbs

The result ***might*** give you some pointers.

 

[RayportingMonkey]

Sorry, I've almost run out of ideas. Here is what I would do:
- Start a console session on the host (by sitting in front of it), using a
Domain Administrator account, then execute the command
cscript //nologo C:\WorkingDirectory\FileName.vbs
- Start a Command Prompt on the host with psexec.exe (while
sitting in front of your laptop), then run the script:
psexec \\YourHost -u DomainName\DomainAdmin cmd{Enter}
cscript //nologo C:\WorkingDirectory\FileName.vbs

The result ***might*** give you some pointers.

Peg - That push was in the right direction!

Even though I am logged in with the same credentials on both machines, this
does seem to be a login/id related issue.

The command that ran with succes was as follows:

psexec \\MyHost -u DomainName\UserName -p UserPassword cscript //nologo
C:\WorkingDirectory\FileName.vbs

I had mentioned earlier in this thread that I did incorporate ID/PASS (-u /
-p) variables in my attempts, but the script had failed. Since doing that I
have modified my IE settings on both machines by adding the domain(s) I am
downloading from as Trusted Sites and in "Custom Level" under security set
the Access Data Sources Across Domains to "Enable" (from Disabled"). On the
desktop pc, under Folder Options, I un-checked the "Use simple file sharing
(Recommended)" option. Each of these measures were reccommended in various
articles I found on-line while researching the error message,
"C:\WorkingDirectory\FileName.vbs(7,1) msxml3.dll: Access is denied".

The only other change I want to document is that I had NOT installed PsExec
on the desktop until now, which I did to execute your recommended test from
PsExec on the desktop (which made perfect sense by the way and I kick myself
for not doing that before posting!).

So a few changes, but I'm not sure which one(s) made the difference.

I do know that you (Pegasus (MVP)) and Louis made a difference by taking the
time to assist - I greatly appreciate it and hope people find this thread
useful if they have a similar issue.

Again, crisis averted - Thank You!

Later-
Ray

 

[Pegasus \(MVP\)]

So a few changes, but I'm not sure which one(s) made the difference.

I do know that you (Pegasus (MVP)) and Louis made a difference by taking
the
time to assist - I greatly appreciate it and hope people find this thread
useful if they have a similar issue.

Again, crisis averted - Thank You!

Later-
Ray

Glad you got it resolved, and thanks for the feedback.

 

[3c273]

Glad you got it sorted. For future reference, there is also rcmd.exe which
uses the rcmdsvc.exe service from the resource kit. I was going to suggest
you try it, but no need now.
Louis