Map network drive to a computer in a workgroup

[Ckoslow]

I have a 2k3 domain and a 2000 server that is in a workgroup due to 3rd party programs/conflicts.

I need to map a share from my domain to the workgroup server.

If I manualy map the drive, it works fine but the when I try the script it doesnt map the drive

Heres the line I am using


WshNetwork.MapNetworkDrive "Q:", "\\192.168.1.244\npc", 2kserver\billuser, passuser

I am not sure if the problem is because I set the strUsername early on. Can I change it to the workgroup username and then change it back the to the domain after the section of script runs.


Here is what i think might be important in the script



strUserName = ""
While strUserName = ""
WScript.Sleep 100 ' 1/10 th of a second
strUserName = WSHNetwork.UserName
Wend
strUserDomain = WSHNetwork.UserDomain
Set ObjGroupDict = CreateMemberOfObject(strUserDomain, strUserName)

' Read the user's account "Member Of" tab info across the network
' once into a dictionary object.

On error resume next

'=========================================================
'=This Section does folder mapping =
'=========================================================


WshNetwork.MapNetworkDrive "Q:", "\\192.168.1.244\npc", 2kserver\billuser, passuser



'*****************************************************************************
'*This ends folder mapping, the following is a function that needs to be here
'*****************************************************************************
Function MemberOf(ObjDict, strKey)


Thanks

 

[EBGreen]

Take out the On Error Resume Next and I think that you will find that the line that does the mapping is syntactically incorrect.

Here is the helpfile for waht the line should be:

object.MapNetworkDrive(strLocalName, strRemoteName, [bUpdateProfile], [strUser], [strPassword])

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[kmcferrin]

On Error Resume Next can be a pain when you're troubleshooting. I try to avoid using it at all if possible, which means writing a Sub to handle errors, but actually getting the error message really saves time and frustration.

On a related note, as annoying as it can be to use Option Explicit and Dim all the variables, it has saved me loads of frustration in cases where I have accidentally mis-spelled a variable name somewhere in the script.

 

[EBGreen]

Yes, I generally advocate two maxims that have gotten me named the code Nazi here at work:

#1 - Only use On Error Resume Next where it must be used. If there is a line that you expect might fail in some instances, but you want the script to continue if it does, then bracket the line with On Error Resume Next and On Error Goto 0.

#2 - Always use Option Explicit. Period. There is absolutely no reason not to.

Even though people belly ache about it I think everyone has come to the conclusion that these are good practices to follow.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[tsuji]

>#2 - Always use Option Explicit. Period. There is absolutely no reason not to.
Always? If you like, yes... else it would be Option Implicit else the functional programmers did not do their job.

 

[EBGreen]

I don't understand your point tsuji. Please explain. You've forgotten more about VBScript than I'll probably ever know, so if there is some reason not to use Option Explicit, I'd like to know it.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[tsuji]

Tom,
I know my position against any statement purporting one must use option explicit (in vbs) to be good "professional" is definitely not popular. One can make it one's own rule of practice, no problem. If it is presented as if an absolute rule to be "good", I vote against without reserve. I think it is pretentious and of vaine mannerism. And I don't want that message spreads without being counteracted upon in peer-reviewed professional forum. I think the best virtue of scripting is its freedom and speed of development. If one surrenders it, one better goes for other languages. If one has the mentality of the script one writes is for eternity like a script on the stone, one will be very disappointed.

I have just digged out a past debate among our very good friends to the vbs forum.

http://tek-tips.com/viewthread.cfm?qid=994358&page=1

Let me make up another artificial example.
[tt]
option explicit
dim msgbox(1,1),y
msgbox(0,1)=1
'after a long excursion
'etc
y=msgbox(0,vbokcancel)
if y=vbok then
createobject("wscript.shell").run "%comspec% /k dir d:"
'"%comspec% /k dir format d:"
end if
[/tt]
With the option explicit you can unknowingly override built-in stuff. It may not be the best illustration of the negative side.
- tsuji

 

[EBGreen]

I was not aware of that feature of Option Explicit. I still think it has the potential for more good than bad, but I can accept that there are valid opinions to the contrary.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[EBGreen]

Tsuji, in my quest for understanding, I took the code that you posted above and tried it. The result I got was exactly the same whether I had Option Explicit in the script or not. I still don't see how this is an argument for not using option explicit. I'm not trying to be argumentative or dense, I truly just want ot unerstand the issue.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[mrmovie]

not being a bible basher myself, can anyone comment on Option Explicit making scripts run faster or slower?

 

[tsuji]

TTKP,
Sure it does not affect the execution of the script. The point is that there are thousand of ways to make a wrong script. Obsessed to dim everything may backfire as shown in that illustration---not a very good one maybe. There are truly important concepts to pick up of the design philosophy of a language or vbs. If the functional designers of it decides that option explicit is an option, it is one. That does not sell very well. I just do not like people hooking up pseudo-professional look and just junk in the functional part. My person guideline is for a good script, not one line is cosmetic. Retiring one line will make it not working. But sometime there is a balancing decision to take.

mrmovie,
I would say, none. It is a design time device.

- tsuji

 

[EBGreen]

Ok, Tsuji, I think I understand now. I can see that there is no true requirement for Option Explicit. I still however maintain my position that since it does no harm and can potentially point out errors that would otherwise potentially be difficult to find, then no harm comes from always using it.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]