I have an issue that I am trying to run a vbscript, that automatically runs
an FTP job. The script worked well in testing, until I tried to run it as a
scheduled task.
An integral part of the script is to map a network drive, that is then
utililised by an FTP task ("lcd e:\"). The problem is that if the script
fails, then the mapped drive is remembered by task scheduler, but it cannot
be viewed by any of the normal methods e.g. net use, Windows Explorer or
subst.

I have found a number of postings with people having the same issues, but am
yet to find a solution.

Any help appreciated.

"Jo Winchester" <JoWinchester@discussions.microsoft.com> wrote in message
news:8F4F1735-2B53-4B62-95D6-4EF87285914C@microsoft.com...
The usual cure is not to map drives by scheduled tasks but use
UNC coding instead.

Another simple cure is to control the scheduled task tightly
and to check at its end if the problem drive is still mapped.
This can be done by embedding the script in a batch file.
The last instruction of the batch file could be

net use x: /del

which would execute even if the script failed.

A third way would be to code the whole thing as a batch
file like so:

@echo off
set script=c:\script.scr
set site=www.yoursite.com
set account=Jack
set password=Jill

echo %account%>%script%
echo %password%>>%script%
echo binary>>%script%
echo get SomeFile.txt >>%script%
echo quit >>%script%

net use x: \\SomeServer\SomeShare
cd /d x:\SomeFolder
ftp -s:%script% %site%
net use x: /del

Thanks for your reply.

However, I cannot map to a UNC path, as the script needs to use a drive
letter i.e. "lcd e:".

Also, I have tried expermenting with a batch file - and running it as a
scheduled tasks. Even running commands by this method does not allow me to
unmap the "ghost" drive mapping. I created a batch file that would output
the results of a "net use" command to a text file - but no drives show. The
only evidence I can get that the drive exists is if I add a line to the batch
file that does "dir e:" and outputs to a text file. This will list the files
that are in the remote location.

Having said all of this, I have tried your suggestion of "net use x: /del"
at the end of my batch file, but it does not recognise that the drive is
mapped.

Finally, yes I agree I could attempt to map the drives simply by using a
batch file outside a vbscript - however the script does a lot more than map a
drive and run an FTP job - it includes a lot of error checking, sends
e-mails, confirms servers are available. Also, the script reads a control
file so that it can carry out multiple file transfers - each time the script
loops, a different drive is mapped - so to try and control this through a
batch file would be very difficult.

Jo

"Pegasus (MVP)" wrote:

You should add some basic reporting tools to the mapping
part of your batch file so that you can see what's going on.
Scheduled batch files ***can*** map files - if you can't see
them then it's due to a coding or permission problem. Try
this:

Line1 @echo off
Line2 echo %date% %time% Start of task > c:\test.log
Line3 echo User=%UserName%, Path=%path% >> c:\test.log
Line4 %SystemRoot%\System32\net.exe use x: \\SomeServer\SomeShare
1>>c:\test.log 2>c:\test.err
Line5 echo ErrorLevel of net.exe=%ErrorLevel% >> c:\test.log
Line6 echo %date% %time% End of task >> c:\test.log

Now have a look at the two log files and all will become clear.


"Jo Winchester" <JoWinchester@discussions.microsoft.com> wrote in message
news:A64B4660-DE42-442F-B9D3-AE05E9C07F23@microsoft.com...

Thanks again for your reply.

I'm not disagreeing that batch files can map drives, I just don't feel that
it is necessarily the right approach for my script - it will add an extra
layer of complexity to what I am trying to acheive. I also don't feel that
it will resolve the underlying issue that I am experiencing.

If you would like to recreate the problem that I have (but beware that the
only method found so far for removing the "ghost" mapped drive is a reboot!)
cut and past the following into a vbscript:

Dim WshNetwork
Set WshNetwork = WScript.CreateObject("WScript.Network")
WshNetwork.MapNetworkDrive "E:", "\\Server\Public"
wscript.echo "Test echo"

and run it as a scheduled task - using wscript. The script will try to echo
to the screen, but as it is running as a scheduled task the echo will not be
visable, and so the script will hang. Then stop the scheduled task by right
clicking and selecting end task.

If you then try to work with the mapped drive via e.g. a batch file, it
won't be possible to remove it, or re-map it. As I said in a previous post,
the only way I have found to prove the existance of the drive is to run "dir
e:" from within a batch file run as a scheduled task - piping the output to a
text file.




"Pegasus (MVP)" wrote:

Sorry, my expertise with wscripts is far too limited to speak
on the subject with any degree of competence or confidence.

When you map a drive letter during a scheduled task then
you must also unmap it during that same task. If you don['t
then you must reboot the machine to free up the drive letter.
Your challenge is to find a way to unmap the drive even when
your script fails. I would have thought that wscript has
sufficiently well developed error handling procedures to
deal with this condition gracefully. With batch files we
take great care not to have any code that could hang a process
(even though it still happens with tools such as ntbackup.exe...)


"Jo Winchester" <JoWinchester@discussions.microsoft.com> wrote in message
news:E1B129FF-B5F4-4549-BDB9-B423B2198B28@microsoft.com...

Thanks again for your quick reply.

Yes - I agree that it is important to include error handling is any script -
and have done just that. However, if you ran the script below, the first
part should successfully map a network drive to e:, then echo the words "Test
echo" to the screen, and finally unmap a e: drive. However, as I mentioned
in my previous note, if this script is run with wscript then the script will
attempt to produce a pop-up box on the screen with the words "test echo"
which needs to be clicked on for the script to proceed. However, as the
script is being run as a scheduled task, the pop-up box will not appear, and
therefore cannot be clicked on, so the script is in a hung state. This means
that the next step of the script cannot be executed. and the scheduled task
has to be ended.

Dim WshNetwork
Set WshNetwork = WScript.CreateObject("WScript.Network")
WshNetwork.MapNetworkDrive "E:", "\\Server\Public"

wscript.echo "Test echo"

Dim WshNetwork
Set WshNetwork = WScript.CreateObject("WScript.Network")
WshNetwork.RemoveNetworkDrive "E:"

When the script I am running goes live, then I won't be running it using
wscript (I will use cscript which won't send any echo's to the screen) and I
will disable any echo's, as they are only enabled for troubleshooting.

So hopefully this issue shouldn't cause us too many issues - but it is a
really annoying bug with Scheduled Tasks.



"Pegasus (MVP)" wrote:

I would use Unix or Linux for this. Far better.