HELP: Mapping Network Drives and Trapping Errors to Return Success

Hello,

I wonder if anyone can help me. I want to be able to use VBScript as
part of a logon script to map a network drive and to return a error on
the basis of weather the mapping was successful or not.

Does anyone know how to do this?

I'm using the MapNetworkDrive function of the WScript.Network object to
do the mapping.

I've enabled "On Error Return Next" and getting the value in Err.Number
however I do not know what codes are returned on success or failure.

Any ideas?

If i can't map drives

Hardeep.

Al
Sun Jul 18 14:10:01 CDT 2004


"Hardeep Rakhra" <mail@rakhra.org.uk> wrote in message
news:2lvs24Fh829iU1@uni-berlin.de...
> Hello,
>
> I wonder if anyone can help me. I want to be able to use VBScript as
> part of a logon script to map a network drive and to return a error on
> the basis of weather the mapping was successful or not.

To whom or to what do you want to "return the error"? Do you just want to
display a pass/fail message to the user?

> Does anyone know how to do this?
>
> I'm using the MapNetworkDrive function of the WScript.Network object to
> do the mapping.
>
> I've enabled "On Error Return Next" and getting the value in Err.Number
> however I do not know what codes are returned on success or failure.

An Err.Number value of zero means success - any other value means failure.
If you want to get a better idea of the nature of an error, try
Err.Description.

In a logon script, it is not going to be of much value to explain the cause
of the failure to the user. They are usually interested only in whether or
not they can work. In any case, most of the reasons for failing to map a
share (server not available, number of share connections exceeded, access
denied, etc) are beyond their capability either to understand or to fix.

Yes, they *could* report an error to IT, but in my experience they are
generally unable to relay the content of any error diagnostic more complex
than "ERROR". If your IT staff are unable to duplicate a problem because it
is not persistent, then you could have your script write diagnostic messages
to a log file on the local hard drive for later examination in the event of
a problem.

Some last quick words of advice: It's a logon script - don't make it more
complicated than it needs to be. Drive mappings should succeed in the vast
majority of cases, so don't get too hung up trying to build in a fancy error
handler. You could spend 90% of your development time on code that will only
run 0.01% of the time. And further, this code will be difficult to test
because it will require that errors happen.

In the simplest case, you could even just use the .DriveExists method of the
File System Object after each MapNetworkDrive call to determine whether or
not it succeeded.

/Al

Hardeep
Sun Jul 18 14:19:22 CDT 2004

Al Dunbar [MS-MVP] wrote:
>
> To whom or to what do you want to "return the error"? Do you just want to
> display a pass/fail message to the user?

> In a logon script, it is not going to be of much value to explain the cause
> of the failure to the user. They are usually interested only in whether or
> not they can work. In any case, most of the reasons for failing to map a
> share (server not available, number of share connections exceeded, access
> denied, etc) are beyond their capability either to understand or to fix.

The main reason for returning the error to that it can be written to
log, so in the event things do start going wrong, we can follow the
where and why of the error. It's somthing i'd rather not report to the
user for all of the reasons you state.

I thought it was a zero returned too, but i've had a 500 returned where
the mapping has suceeded which is what threw me.

I would have thought logging errors in a logon script would have been a
pretty standard feature to include as it makes tracing issues alot
easier in the log run.

Hardeep.

Hardeep
Sun Jul 18 16:17:59 CDT 2004

Al Dunbar [MS-MVP] wrote:

> To whom or to what do you want to "return the error"? Do you just want to
> display a pass/fail message to the user?
>
> In a logon script, it is not going to be of much value to explain the cause
> of the failure to the user. They are usually interested only in whether or
> not they can work. In any case, most of the reasons for failing to map a
> share (server not available, number of share connections exceeded, access
> denied, etc) are beyond their capability either to understand or to fix.

The main reason for returning the error to that it can be written to
log, so in the event things do start going wrong, we can follow the
where and why of the error. It's something i'd rather not report to the
user for all of the reasons you state.

I would have thought logging errors in a logon script would have been a
pretty standard feature to include as it makes tracing issues alot
easier in the long run.

The code I'm using is as follows, my problem is that while the code
works as it is, if i put the code into a sub so i can reuse it it only
works for conditions where the mapping of drives would be successful
else, it does nothing. Not even throw the error.

So while mapping a path that exists works fine, mapping a path that does
not exist does nothing, where it should give a error message, in the
same way it gives a success message.

I can't figure out why this would be the case.

=========================================================================
On Error Resume Next
Dim objNetwork : Set objNetwork = Script.CreateObject("WScript.Network")
' map drive
objNetwork.MapNetworkDrive strDriveLetter, strUNC
' trap errors
If Err.Number <> 0 Then
MsgBox "Mapping Drive: " & strDriveLetter & " To " & strUNC & " [FAILED]"
Else
MsgBox "Mapping Drive: " & strDriveLetter & " To " & strUNC & " [OKAY]"
End If
Set objNetwork = nothing
=========================================================================

Hardeep.

Al
Tue Jul 20 16:49:32 CDT 2004


"Hardeep Rakhra" <mail@rakhra.org.uk> wrote in message
news:2m00poFg49bfU1@uni-berlin.de...
> Al Dunbar [MS-MVP] wrote:
> >
> > To whom or to what do you want to "return the error"? Do you just want
to
> > display a pass/fail message to the user?
>
> > In a logon script, it is not going to be of much value to explain the
cause
> > of the failure to the user. They are usually interested only in whether
or
> > not they can work. In any case, most of the reasons for failing to map a
> > share (server not available, number of share connections exceeded,
access
> > denied, etc) are beyond their capability either to understand or to fix.
>
> The main reason for returning the error to that it can be written to
> log, so in the event things do start going wrong, we can follow the
> where and why of the error. It's somthing i'd rather not report to the
> user for all of the reasons you state.

Are you expecting that things will "start going wrong" for some reason? If
so, what sorts of things are you expecting to see happen?

IMHO, most of the causes of share mapping failure relate to problems that
become obvious, or can be monitored, in some other way. If the server
hosting the share is down, for example, then it will affect everyone mapping
to any shares there. That can often be as easily diagnosed by the help desk
calls.

Most of the other possible causes of failure are similar. However, if it is
a networking problem on the workstation (unplugged?), it is not going to run
the logon script anyway, assuming you run them from netlogon share on a
domain controller.

Finally, it is possible to attempt to map to a non-existent share. That is
generally going to be a hard error, that is, it won't work for a while and
then "start going wrong".

Anticipating what actions in logon scripts might fail is a good thing.
Logging such events, giving the err.number, err.description, time, user, and
etc. is also a good thing. But I still think it can be overdone if you are
not careful. If you log to a network share, well, what happens if there is a
problem accessing that share, and where would you log *that* situation? If
you log to a local file, you will have to have some way to collect the
errors to analyze them.

> I thought it was a zero returned too, but i've had a 500 returned where
> the mapping has suceeded which is what threw me.

Do an err.clear before mapping the drive, just in case. What was the
err.description that corresponded to the 500?

> I would have thought logging errors in a logon script would have been a
> pretty standard feature to include as it makes tracing issues alot
> easier in the log run.

I don't know how common, but we do it (to a local file in the %temp%
folder), and it is definitely worth doing. Mind you, we have only ever used
it to track down the cause of specific problems reported by the users. We
have never proactively analyzed these logs looking for unreported errors.


/Al

Al
Tue Jul 20 16:54:55 CDT 2004


"Hardeep Rakhra" <mail@rakhra.org.uk> wrote in message
news:2m07o7Fh2qpmU1@uni-berlin.de...
> Al Dunbar [MS-MVP] wrote:
>
> > To whom or to what do you want to "return the error"? Do you just want
to
> > display a pass/fail message to the user?
> >
> > In a logon script, it is not going to be of much value to explain the
cause
> > of the failure to the user. They are usually interested only in whether
or
> > not they can work. In any case, most of the reasons for failing to map a
> > share (server not available, number of share connections exceeded,
access
> > denied, etc) are beyond their capability either to understand or to fix.
>
> The main reason for returning the error to that it can be written to
> log, so in the event things do start going wrong, we can follow the
> where and why of the error. It's something i'd rather not report to the
> user for all of the reasons you state.
>
> I would have thought logging errors in a logon script would have been a
> pretty standard feature to include as it makes tracing issues alot
> easier in the long run.
>
> The code I'm using is as follows, my problem is that while the code
> works as it is, if i put the code into a sub so i can reuse it it only
> works for conditions where the mapping of drives would be successful
> else, it does nothing. Not even throw the error.

You'll have to share that version before anyone will be able to suggest what
might be going wrong. One thing, though, is that ON ERROR RESUME NEXT has an
element of "scope" associated. In this snippet:

on error resume next
call sub1

if sub1 does not do its own on error resume next, then when an error occurs
it forces successive subroutine returns until return goes back to the sub
that did do the on error resume next.

> So while mapping a path that exists works fine, mapping a path that does
> not exist does nothing, where it should give a error message, in the
> same way it gives a success message.
>
> I can't figure out why this would be the case.

See my comments above

/Al

> ======================================================
> On Error Resume Next
> Dim objNetwork : Set objNetwork = Script.CreateObject("WScript.Network")
> ' map drive
> objNetwork.MapNetworkDrive strDriveLetter, strUNC
> ' trap errors
> If Err.Number <> 0 Then
> MsgBox "Mapping Drive: " & strDriveLetter & " To " & strUNC & " [FAILED]"
> Else
> MsgBox "Mapping Drive: " & strDriveLetter & " To " & strUNC & " [OKAY]"
> End If
> Set objNetwork = nothing
> =========================================================================
>
> Hardeep.