Create simple file share on the fly

Vinson,

Thanks! However, I can't tell which issue you are especially
recommending since the URL was cut off. See below. Can you
clarify?


On Sep 10, 10:48 pm, Vinson <Vin... RemoveThis @discussions.microsoft.com> wrote:
> I would suggest using WMI. It is like VB script, but has libraries for just
> what you are trying to do. Here is one way to do it:
>
> http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
>
> Vinson
>
> "consultmac2" wrote:
> > I'm trying to find out how to define a file share on the fly
> > (assuming the capability is enabled) via a DOS (or other) command file/
> > script, or perhaps VB as a last resort.
>
> > I'd like to be able to take a user supplied directory on a local
> > drive and be able to temporarily (or perm) associate a file share with
> > it. I'm attempting to work with some compiled programs that I don't
> > have source code access to... that uses this technique to communicate
> > with spawned virtual machines (via virtual LAN).
>
> > Clues, or pointers?
>
> > Thanks

I do see that the link wraps in my original post, but it still works for me.
The mechanics of these forums can be strange.

Below, I have cut the original link in half. You will have to reassemble
the link below by cutting and pasting the first half to the second. Hope
this works.

http://www.microsoft.com/technet/scriptcenter

/resources/qanda/jan05/hey0107.mspx

Vinson

"consultmac2" wrote:

> Vinson,
>
> Thanks! However, I can't tell which issue you are especially
> recommending since the URL was cut off. See below. Can you
> clarify?
>
>
> On Sep 10, 10:48 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > I would suggest using WMI. It is like VB script, but has libraries for just
> > what you are trying to do. Here is one way to do it:
> >
> > http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
> >
> > Vinson
> >
> > "consultmac2" wrote:
> > > I'm trying to find out how to define a file share on the fly
> > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > script, or perhaps VB as a last resort.
> >
> > > I'd like to be able to take a user supplied directory on a local
> > > drive and be able to temporarily (or perm) associate a file share with
> > > it. I'm attempting to work with some compiled programs that I don't
> > > have source code access to... that uses this technique to communicate
> > > with spawned virtual machines (via virtual LAN).
> >
> > > Clues, or pointers?
> >
> > > Thanks
>
>
>

Thanks again for the reference. It does seem like it should be
helpful.

Indeed, I've translated it to perl (ActivePerl) and it does create a
share by the name that I specify, on the folder that I specify. The
thing I'm doing differently than in the example is that I specify my
local computer's name in place of the 'remote' computer's name (since
the example called for creating the share on a remote computer, and my
requirement is different).
Follow-up question #1: Is there a more efficient way to do this for
a folder on the local computer than probing for the computer's name
and specifying it in the place of the 'remote' computer's name?
More important question #2: Could there be something to do with
privileges or rights that I'm not handling with that script? If I
create the share manually via the Windows GUI, the VMWare virtual
machines can access files within that folder/share. But when I have
the script create it, the VMWare virtual machines all fail to be able
to see inside it. Perhaps its related to referring to my local
computer in a 3rd-person fashion? or not?

Thanks.


On Sep 11, 10:06 am, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> I do see that the link wraps in my original post, but it still works for me.
> The mechanics of these forums can be strange.
>
> Below, I have cut the original link in half. You will have to reassemble
> the link below by cutting and pasting the first half to the second. Hope
> this works.
>
> http://www.microsoft.com/technet/scriptcenter
>
> /resources/qanda/jan05/hey0107.mspx
>
> Vinson
>
> "consultmac2" wrote:
> > Vinson,
>
> > Thanks! However, I can't tell which issue you are especially
> > recommending since the URL was cut off. See below. Can you
> > clarify?
>
> > On Sep 10, 10:48 pm, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > what you are trying to do. Here is one way to do it:
>
> > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
>
> > > Vinson
>
> > > "consultmac2" wrote:
> > > > I'm trying to find out how to define a file share on the fly
> > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > script, or perhaps VB as a last resort.
>
> > > > I'd like to be able to take a user supplied directory on a local
> > > > drive and be able to temporarily (or perm) associate a file share with
> > > > it. I'm attempting to work with some compiled programs that I don't
> > > > have source code access to... that uses this technique to communicate
> > > > with spawned virtual machines (via virtual LAN).
>
> > > > Clues, or pointers?
>
> > > > Thanks

There is a simple way to specifiy that the script use the name of the
computer it is being run on. Simply use a period instead of the computer's
name, like so:

strComputer = "."

There is also an environment variable called COMPUTERNAME in virtually every
version of Windows which can be pulled easily into any program. This
variable will obviously have the computer name in it. Drop to DOS, and type
SET to see all the environment variables, listed.

Security Descriptors (rights and permissions) gives me a headache, but
fortunately, there is an article for that, too. Shares have both rights and
permissions, and if you need to change them on the fly, this article should
help. Here ya go...

http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/

Vinson

"consultmac2" wrote:

> Thanks again for the reference. It does seem like it should be
> helpful.
>
> Indeed, I've translated it to perl (ActivePerl) and it does create a
> share by the name that I specify, on the folder that I specify. The
> thing I'm doing differently than in the example is that I specify my
> local computer's name in place of the 'remote' computer's name (since
> the example called for creating the share on a remote computer, and my
> requirement is different).
> Follow-up question #1: Is there a more efficient way to do this for
> a folder on the local computer than probing for the computer's name
> and specifying it in the place of the 'remote' computer's name?
> More important question #2: Could there be something to do with
> privileges or rights that I'm not handling with that script? If I
> create the share manually via the Windows GUI, the VMWare virtual
> machines can access files within that folder/share. But when I have
> the script create it, the VMWare virtual machines all fail to be able
> to see inside it. Perhaps its related to referring to my local
> computer in a 3rd-person fashion? or not?
>
> Thanks.
>
>
> On Sep 11, 10:06 am, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > I do see that the link wraps in my original post, but it still works for me.
> > The mechanics of these forums can be strange.
> >
> > Below, I have cut the original link in half. You will have to reassemble
> > the link below by cutting and pasting the first half to the second. Hope
> > this works.
> >
> > http://www.microsoft.com/technet/scriptcenter
> >
> > /resources/qanda/jan05/hey0107.mspx
> >
> > Vinson
> >
> > "consultmac2" wrote:
> > > Vinson,
> >
> > > Thanks! However, I can't tell which issue you are especially
> > > recommending since the URL was cut off. See below. Can you
> > > clarify?
> >
> > > On Sep 10, 10:48 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > what you are trying to do. Here is one way to do it:
> >
> > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
> >
> > > > Vinson
> >
> > > > "consultmac2" wrote:
> > > > > I'm trying to find out how to define a file share on the fly
> > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > script, or perhaps VB as a last resort.
> >
> > > > > I'd like to be able to take a user supplied directory on a local
> > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > have source code access to... that uses this technique to communicate
> > > > > with spawned virtual machines (via virtual LAN).
> >
> > > > > Clues, or pointers?
> >
> > > > > Thanks
>
>
>

Thanks again Vinson, especially for the "." alias.

I'm familiar with the concepts of security descriptors from other
platforms and remembering some experience I had with it under NT4. I
went through most of the article whose URL you gave me , and a linked
article, as refreshers.
But no matter how I compare the shares made through the script with
the shares that I make from the Windows GUI, I can't find a difference
in any of the Security decriptor settings between them.... even down
in the advanced levels.

But I found another clue to a possible difference. As I said,
when using the script generated shares, none of the vmware virtual
machines (VMs) that reference said share can successfully read
anything in it. But one of the VMs attempts to map the share to a
drive letter (T to use instead. When it hits that line (A 'NET
USE...' command) it throws up an error that the username and password
for that share are invalid (I'm paraphrasing)... and the 'NET USE...'
command isn't including a username at all. But that command works
fine in that VM when attempting to map a share that I 'hand made' via
the GUI.
Soooo, I deduce that the script is creating shares that have at
least some subtle difference in the username and/or password
attributes when compared to the ones that I create via the GUI.
Perhaps the GUI-created ones make some assumptions that the script
does not.
Any ideas down that path? I can't see those attributes reflected
anywhere in the Security tabs of the Properties on those shares. If
the script can't be made to function differently in this regard,
perhaps there's a way to refer to the shares in the VMs in a more
flexible way... to account for the differences. ?

Thanks again.


On Sep 12, 11:26 pm, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> There is a simple way to specifiy that the script use the name of the
> computer it is being run on. Simply use a period instead of the computer's
> name, like so:
>
> strComputer = "."
>
> There is also an environment variable called COMPUTERNAME in virtually every
> version of Windows which can be pulled easily into any program. This
> variable will obviously have the computer name in it. Drop to DOS, and type
> SET to see all the environment variables, listed.
>
> Security Descriptors (rights and permissions) gives me a headache, but
> fortunately, there is an article for that, too. Shares have both rights and
> permissions, and if you need to change them on the fly, this article should
> help. Here ya go...
>
> http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
>
> Vinson
>
> "consultmac2" wrote:
> > Thanks again for the reference. It does seem like it should be
> > helpful.
>
> > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > share by the name that I specify, on the folder that I specify. The
> > thing I'm doing differently than in the example is that I specify my
> > local computer's name in place of the 'remote' computer's name (since
> > the example called for creating the share on a remote computer, and my
> > requirement is different).
> > Follow-up question #1: Is there a more efficient way to do this for
> > a folder on the local computer than probing for the computer's name
> > and specifying it in the place of the 'remote' computer's name?
> > More important question #2: Could there be something to do with
> > privileges or rights that I'm not handling with that script? If I
> > create the share manually via the Windows GUI, the VMWare virtual
> > machines can access files within that folder/share. But when I have
> > the script create it, the VMWare virtual machines all fail to be able
> > to see inside it. Perhaps its related to referring to my local
> > computer in a 3rd-person fashion? or not?
>
> > Thanks.
>
> > On Sep 11, 10:06 am, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> > > I do see that the link wraps in my original post, but it still works for me.
> > > The mechanics of these forums can be strange.
>
> > > Below, I have cut the original link in half. You will have to reassemble
> > > the link below by cutting and pasting the first half to the second. Hope
> > > this works.
>
> > >http://www.microsoft.com/technet/scriptcenter
>
> > > /resources/qanda/jan05/hey0107.mspx
>
> > > Vinson
>
> > > "consultmac2" wrote:
> > > > Vinson,
>
> > > > Thanks! However, I can't tell which issue you are especially
> > > > recommending since the URL was cut off. See below. Can you
> > > > clarify?
>
> > > > On Sep 10, 10:48 pm, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> > > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > > what you are trying to do. Here is one way to do it:
>
> > > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
>
> > > > > Vinson
>
> > > > > "consultmac2" wrote:
> > > > > > I'm trying to find out how to define a file share on the fly
> > > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > > script, or perhaps VB as a last resort.
>
> > > > > > I'd like to be able to take a user supplied directory on a local
> > > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > > have source code access to... that uses this technique to communicate
> > > > > > with spawned virtual machines (via virtual LAN).
>
> > > > > > Clues, or pointers?
>
> > > > > > Thanks

I accept that there must be a subtle difference when creating the share
manually versus WMI, but in tinkering, I cannot reproduce the problem. My
WMI share routine faithfully works. Of course, I am not using Virtual
Machines here to connect; I am using an actual XP Workstation. I wonder if
WMI is having a problem in creating the share, but it has no way to report it
to you. You can place the command line below as the final line in your WMI
script to report any latent errors. It should return 0 if all is well, and
some other number if it is not.

Wscript.Echo errReturn

Other errors:

2 = access denied
8 = unknown problem
9 = Invalid Name
10 = Invalid Level
21 = Invalid Parm
22 = Share Already Exists
23 = Redirected Path
24 = Missing Folder
25 = Missing Server
(Anything else means the operation could not be completed).

You might experiment with actual workstations to see if the script is
working, or if it fails in every instance. Since I cannot reproduce the
trouble, I am not sure what else to suggest. You might also post the salient
portions of your WMI script if you want others to test it or debug it with
you.

Vinson

"consultmac2" wrote:

> Thanks again Vinson, especially for the "." alias.
>
> I'm familiar with the concepts of security descriptors from other
> platforms and remembering some experience I had with it under NT4. I
> went through most of the article whose URL you gave me , and a linked
> article, as refreshers.
> But no matter how I compare the shares made through the script with
> the shares that I make from the Windows GUI, I can't find a difference
> in any of the Security decriptor settings between them.... even down
> in the advanced levels.
>
> But I found another clue to a possible difference. As I said,
> when using the script generated shares, none of the vmware virtual
> machines (VMs) that reference said share can successfully read
> anything in it. But one of the VMs attempts to map the share to a
> drive letter (T to use instead. When it hits that line (A 'NET
> USE...' command) it throws up an error that the username and password
> for that share are invalid (I'm paraphrasing)... and the 'NET USE...'
> command isn't including a username at all. But that command works
> fine in that VM when attempting to map a share that I 'hand made' via
> the GUI.
> Soooo, I deduce that the script is creating shares that have at
> least some subtle difference in the username and/or password
> attributes when compared to the ones that I create via the GUI.
> Perhaps the GUI-created ones make some assumptions that the script
> does not.
> Any ideas down that path? I can't see those attributes reflected
> anywhere in the Security tabs of the Properties on those shares. If
> the script can't be made to function differently in this regard,
> perhaps there's a way to refer to the shares in the VMs in a more
> flexible way... to account for the differences. ?
>
> Thanks again.
>
>
> On Sep 12, 11:26 pm, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> > There is a simple way to specifiy that the script use the name of the
> > computer it is being run on. Simply use a period instead of the computer's
> > name, like so:
> >
> > strComputer = "."
> >
> > There is also an environment variable called COMPUTERNAME in virtually every
> > version of Windows which can be pulled easily into any program. This
> > variable will obviously have the computer name in it. Drop to DOS, and type
> > SET to see all the environment variables, listed.
> >
> > Security Descriptors (rights and permissions) gives me a headache, but
> > fortunately, there is an article for that, too. Shares have both rights and
> > permissions, and if you need to change them on the fly, this article should
> > help. Here ya go...
> >
> > http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
> >
> > Vinson
> >
> > "consultmac2" wrote:
> > > Thanks again for the reference. It does seem like it should be
> > > helpful.
> >
> > > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > > share by the name that I specify, on the folder that I specify. The
> > > thing I'm doing differently than in the example is that I specify my
> > > local computer's name in place of the 'remote' computer's name (since
> > > the example called for creating the share on a remote computer, and my
> > > requirement is different).
> > > Follow-up question #1: Is there a more efficient way to do this for
> > > a folder on the local computer than probing for the computer's name
> > > and specifying it in the place of the 'remote' computer's name?
> > > More important question #2: Could there be something to do with
> > > privileges or rights that I'm not handling with that script? If I
> > > create the share manually via the Windows GUI, the VMWare virtual
> > > machines can access files within that folder/share. But when I have
> > > the script create it, the VMWare virtual machines all fail to be able
> > > to see inside it. Perhaps its related to referring to my local
> > > computer in a 3rd-person fashion? or not?
> >
> > > Thanks.
> >
> > > On Sep 11, 10:06 am, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> > > > I do see that the link wraps in my original post, but it still works for me.
> > > > The mechanics of these forums can be strange.
> >
> > > > Below, I have cut the original link in half. You will have to reassemble
> > > > the link below by cutting and pasting the first half to the second. Hope
> > > > this works.
> >
> > > >http://www.microsoft.com/technet/scriptcenter
> >
> > > > /resources/qanda/jan05/hey0107.mspx
> >
> > > > Vinson
> >
> > > > "consultmac2" wrote:
> > > > > Vinson,
> >
> > > > > Thanks! However, I can't tell which issue you are especially
> > > > > recommending since the URL was cut off. See below. Can you
> > > > > clarify?
> >
> > > > > On Sep 10, 10:48 pm, Vinson <Vin... DeleteThis @discussions.microsoft.com> wrote:
> > > > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > > > what you are trying to do. Here is one way to do it:
> >
> > > > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
> >
> > > > > > Vinson
> >
> > > > > > "consultmac2" wrote:
> > > > > > > I'm trying to find out how to define a file share on the fly
> > > > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > > > script, or perhaps VB as a last resort.
> >
> > > > > > > I'd like to be able to take a user supplied directory on a local
> > > > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > > > have source code access to... that uses this technique to communicate
> > > > > > > with spawned virtual machines (via virtual LAN).
> >
> > > > > > > Clues, or pointers?
> >
> > > > > > > Thanks
>
>
>

Here is the script I was using...

Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objNewShare = objWMIService.Get("Win32_Share")
errReturn = objNewShare.Create _
("C:\test", "Test", FILE_SHARE, _
MAXIMUM_CONNECTIONS, "I nice new share.")
Wscript.Echo errReturn



"Vinson" wrote:

> I accept that there must be a subtle difference when creating the share
> manually versus WMI, but in tinkering, I cannot reproduce the problem. My
> WMI share routine faithfully works. Of course, I am not using Virtual
> Machines here to connect; I am using an actual XP Workstation. I wonder if
> WMI is having a problem in creating the share, but it has no way to report it
> to you. You can place the command line below as the final line in your WMI
> script to report any latent errors. It should return 0 if all is well, and
> some other number if it is not.
>
> Wscript.Echo errReturn
>
> Other errors:
>
> 2 = access denied
> 8 = unknown problem
> 9 = Invalid Name
> 10 = Invalid Level
> 21 = Invalid Parm
> 22 = Share Already Exists
> 23 = Redirected Path
> 24 = Missing Folder
> 25 = Missing Server
> (Anything else means the operation could not be completed).
>
> You might experiment with actual workstations to see if the script is
> working, or if it fails in every instance. Since I cannot reproduce the
> trouble, I am not sure what else to suggest. You might also post the salient
> portions of your WMI script if you want others to test it or debug it with
> you.
>
> Vinson
>
> "consultmac2" wrote:
>
> > Thanks again Vinson, especially for the "." alias.
> >
> > I'm familiar with the concepts of security descriptors from other
> > platforms and remembering some experience I had with it under NT4. I
> > went through most of the article whose URL you gave me , and a linked
> > article, as refreshers.
> > But no matter how I compare the shares made through the script with
> > the shares that I make from the Windows GUI, I can't find a difference
> > in any of the Security decriptor settings between them.... even down
> > in the advanced levels.
> >
> > But I found another clue to a possible difference. As I said,
> > when using the script generated shares, none of the vmware virtual
> > machines (VMs) that reference said share can successfully read
> > anything in it. But one of the VMs attempts to map the share to a
> > drive letter (T to use instead. When it hits that line (A 'NET
> > USE...' command) it throws up an error that the username and password
> > for that share are invalid (I'm paraphrasing)... and the 'NET USE...'
> > command isn't including a username at all. But that command works
> > fine in that VM when attempting to map a share that I 'hand made' via
> > the GUI.
> > Soooo, I deduce that the script is creating shares that have at
> > least some subtle difference in the username and/or password
> > attributes when compared to the ones that I create via the GUI.
> > Perhaps the GUI-created ones make some assumptions that the script
> > does not.
> > Any ideas down that path? I can't see those attributes reflected
> > anywhere in the Security tabs of the Properties on those shares. If
> > the script can't be made to function differently in this regard,
> > perhaps there's a way to refer to the shares in the VMs in a more
> > flexible way... to account for the differences. ?
> >
> > Thanks again.
> >
> >
> > On Sep 12, 11:26 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > There is a simple way to specifiy that the script use the name of the
> > > computer it is being run on. Simply use a period instead of the computer's
> > > name, like so:
> > >
> > > strComputer = "."
> > >
> > > There is also an environment variable called COMPUTERNAME in virtually every
> > > version of Windows which can be pulled easily into any program. This
> > > variable will obviously have the computer name in it. Drop to DOS, and type
> > > SET to see all the environment variables, listed.
> > >
> > > Security Descriptors (rights and permissions) gives me a headache, but
> > > fortunately, there is an article for that, too. Shares have both rights and
> > > permissions, and if you need to change them on the fly, this article should
> > > help. Here ya go...
> > >
> > > http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
> > >
> > > Vinson
> > >
> > > "consultmac2" wrote:
> > > > Thanks again for the reference. It does seem like it should be
> > > > helpful.
> > >
> > > > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > > > share by the name that I specify, on the folder that I specify. The
> > > > thing I'm doing differently than in the example is that I specify my
> > > > local computer's name in place of the 'remote' computer's name (since
> > > > the example called for creating the share on a remote computer, and my
> > > > requirement is different).
> > > > Follow-up question #1: Is there a more efficient way to do this for
> > > > a folder on the local computer than probing for the computer's name
> > > > and specifying it in the place of the 'remote' computer's name?
> > > > More important question #2: Could there be something to do with
> > > > privileges or rights that I'm not handling with that script? If I
> > > > create the share manually via the Windows GUI, the VMWare virtual
> > > > machines can access files within that folder/share. But when I have
> > > > the script create it, the VMWare virtual machines all fail to be able
> > > > to see inside it. Perhaps its related to referring to my local
> > > > computer in a 3rd-person fashion? or not?
> > >
> > > > Thanks.
> > >
> > > > On Sep 11, 10:06 am, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > > > I do see that the link wraps in my original post, but it still works for me.
> > > > > The mechanics of these forums can be strange.
> > >
> > > > > Below, I have cut the original link in half. You will have to reassemble
> > > > > the link below by cutting and pasting the first half to the second. Hope
> > > > > this works.
> > >
> > > > >http://www.microsoft.com/technet/scriptcenter
> > >
> > > > > /resources/qanda/jan05/hey0107.mspx
> > >
> > > > > Vinson
> > >
> > > > > "consultmac2" wrote:
> > > > > > Vinson,
> > >
> > > > > > Thanks! However, I can't tell which issue you are especially
> > > > > > recommending since the URL was cut off. See below. Can you
> > > > > > clarify?
> > >
> > > > > > On Sep 10, 10:48 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > > > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > > > > what you are trying to do. Here is one way to do it:
> > >
> > > > > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
> > >
> > > > > > > Vinson
> > >
> > > > > > > "consultmac2" wrote:
> > > > > > > > I'm trying to find out how to define a file share on the fly
> > > > > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > > > > script, or perhaps VB as a last resort.
> > >
> > > > > > > > I'd like to be able to take a user supplied directory on a local
> > > > > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > > > > have source code access to... that uses this technique to communicate
> > > > > > > > with spawned virtual machines (via virtual LAN).
> > >
> > > > > > > > Clues, or pointers?
> > >
> > > > > > > > Thanks
> >
> >
> >

Thanks for the idea of trying it between two computers rather than
using just between the VMs and the host computer.

Whether or not that's what made me discover another difference or
not.... I have discovered another difference between the permissions
on the two types of shares (created manually via the GUI versus
created through use of the script sub below...).
The handmade shares show four items under the 'Group or user
names:' pane in the Security tab of the properties sheet:
Administrators (xyz\Administrators), Barry (xyz\Barry), Everyone and
SYSTEM. These are shares that are accessed sucessfully from VMs and
other computers.
BUT.... The shares that are created by the script sub below are
missing the 'Everyone' entry in that 'Group or user names:'
list!!!
When I manually add the everyone group to the list, those shares
are accessible from the VMs and other computers. What's going wrong
with the script, I wonder!!??!!

Below is the sub, in Perl, that I'm using.

sub processSharable{
my $dirtoshare = $_[0];
my $sharename = $_[1];

my $FILE_SHARE = 0;
#my $mynode = Win32::NodeName();
my $strComputer = '.';
my $MAXIMUM_CONNECTIONS = 25;

my $objWMIService = Win32::OLE->GetObject('winmgmts:\\\\' .
$strComputer . '\\root\\cimv2');

my $objNewShare = $objWMIService->Get('Win32_Share');

my $errReturn = $objNewShare->Create ($dirtoshare, $sharename,
$FILE_SHARE,
$MAXIMUM_CONNECTIONS, 'Public share for Fabrikam employees.');
}


On Sep 14, 2:20 am, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> Here is the script I was using...
>
> Const FILE_SHARE = 0
> Const MAXIMUM_CONNECTIONS = 25
> strComputer = "."
> Set objWMIService = GetObject("winmgmts:" _
> & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
> Set objNewShare = objWMIService.Get("Win32_Share")
> errReturn = objNewShare.Create _
> ("C:\test", "Test", FILE_SHARE, _
> MAXIMUM_CONNECTIONS, "I nice new share.")
> Wscript.Echo errReturn
>
> "Vinson" wrote:
> > I accept that there must be a subtle difference when creating the share
> > manually versus WMI, but in tinkering, I cannot reproduce the problem. My
> > WMI share routine faithfully works. Of course, I am not using Virtual
> > Machines here to connect; I am using an actual XP Workstation. I wonder if
> > WMI is having a problem in creating the share, but it has no way to report it
> > to you. You can place the command line below as the final line in your WMI
> > script to report any latent errors. It should return 0 if all is well, and
> > some other number if it is not.
>
> > Wscript.Echo errReturn
>
> > Other errors:
>
> > 2 = access denied
> > 8 = unknown problem
> > 9 = Invalid Name
> > 10 = Invalid Level
> > 21 = Invalid Parm
> > 22 = Share Already Exists
> > 23 = Redirected Path
> > 24 = Missing Folder
> > 25 = Missing Server
> > (Anything else means the operation could not be completed).
>
> > You might experiment with actual workstations to see if the script is
> > working, or if it fails in every instance. Since I cannot reproduce the
> > trouble, I am not sure what else to suggest. You might also post the salient
> > portions of your WMI script if you want others to test it or debug it with
> > you.
>
> > Vinson
>
> > "consultmac2" wrote:
>
> > > Thanks again Vinson, especially for the "." alias.
>
> > > I'm familiar with the concepts of security descriptors from other
> > > platforms and remembering some experience I had with it under NT4. I
> > > went through most of the article whose URL you gave me , and a linked
> > > article, as refreshers.
> > > But no matter how I compare the shares made through the script with
> > > the shares that I make from the Windows GUI, I can't find a difference
> > > in any of the Security decriptor settings between them.... even down
> > > in the advanced levels.
>
> > > But I found another clue to a possible difference. As I said,
> > > when using the script generated shares, none of the vmware virtual
> > > machines (VMs) that reference said share can successfully read
> > > anything in it. But one of the VMs attempts to map the share to a
> > > drive letter (T to use instead. When it hits that line (A 'NET
> > > USE...' command) it throws up an error that the username and password
> > > for that share are invalid (I'm paraphrasing)... and the 'NET USE...'
> > > command isn't including a username at all. But that command works
> > > fine in that VM when attempting to map a share that I 'hand made' via
> > > the GUI.
> > > Soooo, I deduce that the script is creating shares that have at
> > > least some subtle difference in the username and/or password
> > > attributes when compared to the ones that I create via the GUI.
> > > Perhaps the GUI-created ones make some assumptions that the script
> > > does not.
> > > Any ideas down that path? I can't see those attributes reflected
> > > anywhere in the Security tabs of the Properties on those shares. If
> > > the script can't be made to function differently in this regard,
> > > perhaps there's a way to refer to the shares in the VMs in a more
> > > flexible way... to account for the differences. ?
>
> > > Thanks again.
>
> > > On Sep 12, 11:26 pm, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> > > > There is a simple way to specifiy that the script use the name of the
> > > > computer it is being run on. Simply use a period instead of the computer's
> > > > name, like so:
>
> > > > strComputer = "."
>
> > > > There is also an environment variable called COMPUTERNAME in virtually every
> > > > version of Windows which can be pulled easily into any program. This
> > > > variable will obviously have the computer name in it. Drop to DOS, and type
> > > > SET to see all the environment variables, listed.
>
> > > > Security Descriptors (rights and permissions) gives me a headache, but
> > > > fortunately, there is an article for that, too. Shares have both rights and
> > > > permissions, and if you need to change them on the fly, this article should
> > > > help. Here ya go...
>
> > > >http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
>
> > > > Vinson
>
> > > > "consultmac2" wrote:
> > > > > Thanks again for the reference. It does seem like it should be
> > > > > helpful.
>
> > > > > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > > > > share by the name that I specify, on the folder that I specify. The
> > > > > thing I'm doing differently than in the example is that I specify my
> > > > > local computer's name in place of the 'remote' computer's name (since
> > > > > the example called for creating the share on a remote computer, and my
> > > > > requirement is different).
> > > > > Follow-up question #1: Is there a more efficient way to do this for
> > > > > a folder on the local computer than probing for the computer's name
> > > > > and specifying it in the place of the 'remote' computer's name?
> > > > > More important question #2: Could there be something to do with
> > > > > privileges or rights that I'm not handling with that script? If I
> > > > > create the share manually via the Windows GUI, the VMWare virtual
> > > > > machines can access files within that folder/share. But when I have
> > > > > the script create it, the VMWare virtual machines all fail to be able
> > > > > to see inside it. Perhaps its related to referring to my local
> > > > > computer in a 3rd-person fashion? or not?
>
> > > > > Thanks.
>
> > > > > On Sep 11, 10:06 am, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> > > > > > I do see that the link wraps in my original post, but it still works for me.
> > > > > > The mechanics of these forums can be strange.
>
> > > > > > Below, I have cut the original link in half. You will have to reassemble
> > > > > > the link below by cutting and pasting the first half to the second. Hope
> > > > > > this works.
>
> > > > > >http://www.microsoft.com/technet/scriptcenter
>
> > > > > > /resources/qanda/jan05/hey0107.mspx
>
> > > > > > Vinson
>
> > > > > > "consultmac2" wrote:
> > > > > > > Vinson,
>
> > > > > > > Thanks! However, I can't tell which issue you are especially
> > > > > > > recommending since the URL was cut off. See below. Can you
> > > > > > > clarify?
>
> > > > > > > On Sep 10, 10:48 pm, Vinson <Vin....TakeThisOut@discussions.microsoft.com> wrote:
> > > > > > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > > > > > what you are trying to do. Here is one way to do it:
>
> > > > > > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
>
> > > > > > > > Vinson
>
> > > > > > > > "consultmac2" wrote:
> > > > > > > > > I'm trying to find out how to define a file share on the fly
> > > > > > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > > > > > script, or perhaps VB as a last resort.
>
> > > > > > > > > I'd like to be able to take a user supplied directory on a local
> > > > > > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > > > > > have source code access to... that uses this technique to communicate
> > > > > > > > > with spawned virtual machines (via virtual LAN).
>
> > > > > > > > > Clues, or pointers?
>
> > > > > > > > > Thanks

I believe you have provided the answer to this mystery. =D

If you programatically add the 'Everyone' Group to the Folder, I bet it
works. There are fancy coding methods to change security descriptors (as you
have seen), but why not shell out of your Perl script and run a DOS command
that will apply the group "Everyone" to your folder after you create your
share? I believe it would be easier than tinkering with Security
Descriptors, in WMI script.

CACLS.EXE <---- The Tool

cacls "c:\sampledir" /t /e /c /g Everyone:F

The sample command above would apply the group 'Everyone' to the folder
SAMPLEDIR with full NTFS permissions which would also be applied to all the
files in the directory. Be sure to always use the /E argument, or you will
replace all DACLs with a single entry rather than edit them. Be sure to
quote directories or files that have spaces such as "C:\Program Files."

Here is a reference for the command.
http://www.microsoft.com/resources/documentation/windows/xp/all/proddo...en-us/c

I bet this will do it. Good luck!

Vinson

In the above sample,

"consultmac2" wrote:

> Thanks for the idea of trying it between two computers rather than
> using just between the VMs and the host computer.
>
> Whether or not that's what made me discover another difference or
> not.... I have discovered another difference between the permissions
> on the two types of shares (created manually via the GUI versus
> created through use of the script sub below...).
> The handmade shares show four items under the 'Group or user
> names:' pane in the Security tab of the properties sheet:
> Administrators (xyz\Administrators), Barry (xyz\Barry), Everyone and
> SYSTEM. These are shares that are accessed sucessfully from VMs and
> other computers.
> BUT.... The shares that are created by the script sub below are
> missing the 'Everyone' entry in that 'Group or user names:'
> list!!!
> When I manually add the everyone group to the list, those shares
> are accessible from the VMs and other computers. What's going wrong
> with the script, I wonder!!??!!
>
> Below is the sub, in Perl, that I'm using.
>
> sub processSharable{
> my $dirtoshare = $_[0];
> my $sharename = $_[1];
>
> my $FILE_SHARE = 0;
> #my $mynode = Win32::NodeName();
> my $strComputer = '.';
> my $MAXIMUM_CONNECTIONS = 25;
>
> my $objWMIService = Win32::OLE->GetObject('winmgmts:\\\\' .
> $strComputer . '\\root\\cimv2');
>
> my $objNewShare = $objWMIService->Get('Win32_Share');
>
> my $errReturn = $objNewShare->Create ($dirtoshare, $sharename,
> $FILE_SHARE,
> $MAXIMUM_CONNECTIONS, 'Public share for Fabrikam employees.');
> }
>
>
> On Sep 14, 2:20 am, Vinson <Vin... RemoveThis @discussions.microsoft.com> wrote:
> > Here is the script I was using...
> >
> > Const FILE_SHARE = 0
> > Const MAXIMUM_CONNECTIONS = 25
> > strComputer = "."
> > Set objWMIService = GetObject("winmgmts:" _
> > & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
> > Set objNewShare = objWMIService.Get("Win32_Share")
> > errReturn = objNewShare.Create _
> > ("C:\test", "Test", FILE_SHARE, _
> > MAXIMUM_CONNECTIONS, "I nice new share.")
> > Wscript.Echo errReturn
> >
> > "Vinson" wrote:
> > > I accept that there must be a subtle difference when creating the share
> > > manually versus WMI, but in tinkering, I cannot reproduce the problem. My
> > > WMI share routine faithfully works. Of course, I am not using Virtual
> > > Machines here to connect; I am using an actual XP Workstation. I wonder if
> > > WMI is having a problem in creating the share, but it has no way to report it
> > > to you. You can place the command line below as the final line in your WMI
> > > script to report any latent errors. It should return 0 if all is well, and
> > > some other number if it is not.
> >
> > > Wscript.Echo errReturn
> >
> > > Other errors:
> >
> > > 2 = access denied
> > > 8 = unknown problem
> > > 9 = Invalid Name
> > > 10 = Invalid Level
> > > 21 = Invalid Parm
> > > 22 = Share Already Exists
> > > 23 = Redirected Path
> > > 24 = Missing Folder
> > > 25 = Missing Server
> > > (Anything else means the operation could not be completed).
> >
> > > You might experiment with actual workstations to see if the script is
> > > working, or if it fails in every instance. Since I cannot reproduce the
> > > trouble, I am not sure what else to suggest. You might also post the salient
> > > portions of your WMI script if you want others to test it or debug it with
> > > you.
> >
> > > Vinson
> >
> > > "consultmac2" wrote:
> >
> > > > Thanks again Vinson, especially for the "." alias.
> >
> > > > I'm familiar with the concepts of security descriptors from other
> > > > platforms and remembering some experience I had with it under NT4. I
> > > > went through most of the article whose URL you gave me , and a linked
> > > > article, as refreshers.
> > > > But no matter how I compare the shares made through the script with
> > > > the shares that I make from the Windows GUI, I can't find a difference
> > > > in any of the Security decriptor settings between them.... even down
> > > > in the advanced levels.
> >
> > > > But I found another clue to a possible difference. As I said,
> > > > when using the script generated shares, none of the vmware virtual
> > > > machines (VMs) that reference said share can successfully read
> > > > anything in it. But one of the VMs attempts to map the share to a
> > > > drive letter (T to use instead. When it hits that line (A 'NET
> > > > USE...' command) it throws up an error that the username and password
> > > > for that share are invalid (I'm paraphrasing)... and the 'NET USE...'
> > > > command isn't including a username at all. But that command works
> > > > fine in that VM when attempting to map a share that I 'hand made' via
> > > > the GUI.
> > > > Soooo, I deduce that the script is creating shares that have at
> > > > least some subtle difference in the username and/or password
> > > > attributes when compared to the ones that I create via the GUI.
> > > > Perhaps the GUI-created ones make some assumptions that the script
> > > > does not.
> > > > Any ideas down that path? I can't see those attributes reflected
> > > > anywhere in the Security tabs of the Properties on those shares. If
> > > > the script can't be made to function differently in this regard,
> > > > perhaps there's a way to refer to the shares in the VMs in a more
> > > > flexible way... to account for the differences. ?
> >
> > > > Thanks again.
> >
> > > > On Sep 12, 11:26 pm, Vinson <Vin... RemoveThis @discussions.microsoft.com> wrote:
> > > > > There is a simple way to specifiy that the script use the name of the
> > > > > computer it is being run on. Simply use a period instead of the computer's
> > > > > name, like so:
> >
> > > > > strComputer = "."
> >
> > > > > There is also an environment variable called COMPUTERNAME in virtually every
> > > > > version of Windows which can be pulled easily into any program. This
> > > > > variable will obviously have the computer name in it. Drop to DOS, and type
> > > > > SET to see all the environment variables, listed.
> >
> > > > > Security Descriptors (rights and permissions) gives me a headache, but
> > > > > fortunately, there is an article for that, too. Shares have both rights and
> > > > > permissions, and if you need to change them on the fly, this article should
> > > > > help. Here ya go...
> >
> > > > >http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
> >
> > > > > Vinson
> >
> > > > > "consultmac2" wrote:
> > > > > > Thanks again for the reference. It does seem like it should be
> > > > > > helpful.
> >
> > > > > > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > > > > > share by the name that I specify, on the folder that I specify. The
> > > > > > thing I'm doing differently than in the example is that I specify my
> > > > > > local computer's name in place of the 'remote' computer's name (since
> > > > > > the example called for creating the share on a remote computer, and my
> > > > > > requirement is different).
> > > > > > Follow-up question #1: Is there a more efficient way to do this for
> > > > > > a folder on the local computer than probing for the computer's name
> > > > > > and specifying it in the place of the 'remote' computer's name?
> > > > > > More important question #2: Could there be something to do with
> > > > > > privileges or rights that I'm not handling with that script? If I
> > > > > > create the share manually via the Windows GUI, the VMWare virtual
> > > > > > machines can access files within that folder/share. But when I have
> > > > > > the script create it, the VMWare virtual machines all fail to be able
> > > > > > to see inside it. Perhaps its related to referring to my local
> > > > > > computer in a 3rd-person fashion? or not?
> >
> > > > > > Thanks.
> >
> > > > > > On Sep 11, 10:06 am, Vinson <Vin... RemoveThis @discussions.microsoft.com> wrote:
> > > > > > > I do see that the link wraps in my original post, but it still works for me.
> > > > > > > The mechanics of these forums can be strange.
> >
> > > > > > > Below, I have cut the original link in half. You will have to reassemble
> > > > > > > the link below by cutting and pasting the first half to the second. Hope
> > > > > > > this works.
> >
> > > > > > >http://www.microsoft.com/technet/scriptcenter
> >
> > > > > > > /resources/qanda/jan05/hey0107.mspx
> >
> > > > > > > Vinson
> >
> > > > > > > "consultmac2" wrote:
> > > > > > > > Vinson,
> >
> > > > > > > > Thanks! However, I can't tell which issue you are especially
> > > > > > > > recommending since the URL was cut off. See below. Can you
> > > > > > > > clarify?
> >
> > > > > > > > On Sep 10, 10:48 pm, Vinson <Vin... RemoveThis @discussions.microsoft.com> wrote:
> > > > > > > > > I would suggest using WMI. It is like VB script, but has libraries for just
> > > > > > > > > what you are trying to do. Here is one way to do it:
> >
> > > > > > > > >http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/h...
> >
> > > > > > > > > Vinson
> >
> > > > > > > > > "consultmac2" wrote:
> > > > > > > > > > I'm trying to find out how to define a file share on the fly
> > > > > > > > > > (assuming the capability is enabled) via a DOS (or other) command file/
> > > > > > > > > > script, or perhaps VB as a last resort.
> >
> > > > > > > > > > I'd like to be able to take a user supplied directory on a local
> > > > > > > > > > drive and be able to temporarily (or perm) associate a file share with
> > > > > > > > > > it. I'm attempting to work with some compiled programs that I don't
> > > > > > > > > > have source code access to... that uses this technique to communicate
> > > > > > > > > > with spawned virtual machines (via virtual LAN).
> >
> > > > > > > > > > Clues, or pointers?
> >
> > > > > > > > > > Thanks
>
>
>

consultmac2 wrote:
> I'm trying to find out how to define a file share on the fly
> (assuming the capability is enabled) via a DOS (or other) command file/
> script, or perhaps VB as a last resort.
>
> I'd like to be able to take a user supplied directory on a local
> drive and be able to temporarily (or perm) associate a file share with
> it. I'm attempting to work with some compiled programs that I don't
> have source code access to... that uses this technique to communicate
> with spawned virtual machines (via virtual LAN).
>
> Clues, or pointers?
>
> Thanks
>
Try the net share command from command prompt.
you can create bat file to run as needed

Using a system call to perform the cacls function was a good idea.
Thanks. While it did help in the long run, just adding it to my
previous script did not make the folder completely accessible as I'd
hoped.
It did indeed seem to add the 'Everyone' group, but the folders
continued to be resistant to access from within the VMs.

The good news is that the call to the cacls tool is part of the
final solution. See my reply to Marty K.

On Sep 14, 4:54 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> I believe you have provided the answer to this mystery. =D
>
> If you programatically add the 'Everyone' Group to the Folder, I bet it
> works. There are fancy coding methods to change security descriptors (as you
> have seen), but why not shell out of your Perl script and run a DOS command
> that will apply the group "Everyone" to your folder after you create your
> share? I believe it would be easier than tinkering with Security
> Descriptors, in WMI script.
>
> CACLS.EXE <---- The Tool
>
> cacls "c:\sampledir" /t /e /c /g Everyone:F
>
> The sample command above would apply the group 'Everyone' to the folder
> SAMPLEDIR with full NTFS permissions which would also be applied to all the
> files in the directory. Be sure to always use the /E argument, or you will
> replace all DACLs with a single entry rather than edit them. Be sure to
> quote directories or files that have spaces such as "C:\Program Files."
>
> Here is a reference for the command.http://www.microsoft.com/resources/documentation/windows/xp/all/prodd...
>
> I bet this will do it. Good luck!
>
> Vinson
>
> In the above sample,
>
> "consultmac2" wrote:
> > Thanks for the idea of trying it between two computers rather than
> > using just between the VMs and the host computer.
>
> > Whether or not that's what made me discover another difference or
> > not.... I have discovered another difference between the permissions
> > on the two types of shares (created manually via the GUI versus
> > created through use of the script sub below...).
> > The handmade shares show four items under the 'Group or user
> > names:' pane in the Security tab of the properties sheet:
> > Administrators (xyz\Administrators), Barry (xyz\Barry), Everyone and
> > SYSTEM. These are shares that are accessed sucessfully from VMs and
> > other computers.
> > BUT.... The shares that are created by the script sub below are
> > missing the 'Everyone' entry in that 'Group or user names:'
> > list!!!
> > When I manually add the everyone group to the list, those shares
> > are accessible from the VMs and other computers. What's going wrong
> > with the script, I wonder!!??!!
>
> > Below is the sub, in Perl, that I'm using.
>
> > sub processSharable{
> > my $dirtoshare = $_[0];
> > my $sharename = $_[1];
>
> > my $FILE_SHARE = 0;
> > #my $mynode = Win32::NodeName();
> > my $strComputer = '.';
> > my $MAXIMUM_CONNECTIONS = 25;
>
> > my $objWMIService = Win32::OLE->GetObject('winmgmts:\\\\' .
> > $strComputer . '\\root\\cimv2');
>
> > my $objNewShare = $objWMIService->Get('Win32_Share');
>
> > my $errReturn = $objNewShare->Create ($dirtoshare, $sharename,
> > $FILE_SHARE,
> > $MAXIMUM_CONNECTIONS, 'Public share for Fabrikam employees.');
> > }
>
> > On Sep 14, 2:20 am, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > Here is the script I was using...
>
> > > Const FILE_SHARE = 0
> > > Const MAXIMUM_CONNECTIONS = 25
> > > strComputer = "."
> > > Set objWMIService = GetObject("winmgmts:" _
> > > & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
> > > Set objNewShare = objWMIService.Get("Win32_Share")
> > > errReturn = objNewShare.Create _
> > > ("C:\test", "Test", FILE_SHARE, _
> > > MAXIMUM_CONNECTIONS, "I nice new share.")
> > > Wscript.Echo errReturn
>
> > > "Vinson" wrote:
> > > > I accept that there must be a subtle difference when creating the share
> > > > manually versus WMI, but in tinkering, I cannot reproduce the problem. My
> > > > WMI share routine faithfully works. Of course, I am not using Virtual
> > > > Machines here to connect; I am using an actual XP Workstation. I wonder if
> > > > WMI is having a problem in creating the share, but it has no way to report it
> > > > to you. You can place the command line below as the final line in your WMI
> > > > script to report any latent errors. It should return 0 if all is well, and
> > > > some other number if it is not.
>
> > > > Wscript.Echo errReturn
>
> > > > Other errors:
>
> > > > 2 = access denied
> > > > 8 = unknown problem
> > > > 9 = Invalid Name
> > > > 10 = Invalid Level
> > > > 21 = Invalid Parm
> > > > 22 = Share Already Exists
> > > > 23 = Redirected Path
> > > > 24 = Missing Folder
> > > > 25 = Missing Server
> > > > (Anything else means the operation could not be completed).
>
> > > > You might experiment with actual workstations to see if the script is
> > > > working, or if it fails in every instance. Since I cannot reproduce the
> > > > trouble, I am not sure what else to suggest. You might also post the salient
> > > > portions of your WMI script if you want others to test it or debug it with
> > > > you.
>
> > > > Vinson
>
> > > > "consultmac2" wrote:
>
> > > > > Thanks again Vinson, especially for the "." alias.
>
> > > > > I'm familiar with the concepts of security descriptors from other
> > > > > platforms and remembering some experience I had with it under NT4.. I
> > > > > went through most of the article whose URL you gave me , and a linked
> > > > > article, as refreshers.
> > > > > But no matter how I compare the shares made through the script with
> > > > > the shares that I make from the Windows GUI, I can't find a difference
> > > > > in any of the Security decriptor settings between them.... even down
> > > > > in the advanced levels.
>
> > > > > But I found another clue to a possible difference. As I said,
> > > > > when using the script generated shares, none of the vmware virtual
> > > > > machines (VMs) that reference said share can successfully read
> > > > > anything in it. But one of the VMs attempts to map the share to a
> > > > > drive letter (T to use instead. When it hits that line (A 'NET
> > > > > USE...' command) it throws up an error that the username and password
> > > > > for that share are invalid (I'm paraphrasing)... and the 'NET USE....'
> > > > > command isn't including a username at all. But that command works
> > > > > fine in that VM when attempting to map a share that I 'hand made' via
> > > > > the GUI.
> > > > > Soooo, I deduce that the script is creating shares that have at
> > > > > least some subtle difference in the username and/or password
> > > > > attributes when compared to the ones that I create via the GUI.
> > > > > Perhaps the GUI-created ones make some assumptions that the script
> > > > > does not.
> > > > > Any ideas down that path? I can't see those attributes reflected
> > > > > anywhere in the Security tabs of the Properties on those shares. If
> > > > > the script can't be made to function differently in this regard,
> > > > > perhaps there's a way to refer to the shares in the VMs in a more
> > > > > flexible way... to account for the differences. ?
>
> > > > > Thanks again.
>
> > > > > On Sep 12, 11:26 pm, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > > > > There is a simple way to specifiy that the script use the name of the
> > > > > > computer it is being run on. Simply use a period instead of the computer's
> > > > > > name, like so:
>
> > > > > > strComputer = "."
>
> > > > > > There is also an environment variable called COMPUTERNAME in virtually every
> > > > > > version of Windows which can be pulled easily into any program. This
> > > > > > variable will obviously have the computer name in it. Drop to DOS, and type
> > > > > > SET to see all the environment variables, listed.
>
> > > > > > Security Descriptors (rights and permissions) gives me a headache, but
> > > > > > fortunately, there is an article for that, too. Shares have both rights and
> > > > > > permissions, and if you need to change them on the fly, this article should
> > > > > > help. Here ya go...
>
> > > > > >http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/
>
> > > > > > Vinson
>
> > > > > > "consultmac2" wrote:
> > > > > > > Thanks again for the reference. It does seem like it should be
> > > > > > > helpful.
>
> > > > > > > Indeed, I've translated it to perl (ActivePerl) and it does create a
> > > > > > > share by the name that I specify, on the folder that I specify. The
> > > > > > > thing I'm doing differently than in the example is that I specify my
> > > > > > > local computer's name in place of the 'remote' computer's name (since
> > > > > > > the example called for creating the share on a remote computer, and my
> > > > > > > requirement is different).
> > > > > > > Follow-up question #1: Is there a more efficient way to do this for
> > > > > > > a folder on the local computer than probing for the computer's name
> > > > > > > and specifying it in the place of the 'remote' computer's name?
> > > > > > > More important question #2: Could there be something to do with
> > > > > > > privileges or rights that I'm not handling with that script? If I
> > > > > > > create the share manually via the Windows GUI, the VMWare virtual
> > > > > > > machines can access files within that folder/share. But when I have
> > > > > > > the script create it, the VMWare virtual machines all fail to be able
> > > > > > > to see inside it. Perhaps its related to referring to my local
> > > > > > > computer in a 3rd-person fashion? or not?
>
> > > > > > > Thanks.
>
> > > > > > > On Sep 11, 10:06 am, Vinson <Vin....DeleteThis@discussions.microsoft.com> wrote:
> > > > > > > > I do see that the link wraps in my original post, but it still works for me.
> > > > > > > > The mechanics of these forums can be strange.
>
> > > > > > > > Below, I have cut the original link in half. You will have to reassemble
> > > > > > > > the link below by cutting and pasting the first half to the second. Hope
> > > > > > > > this works.
>
> > > > > > > >http://www.microsoft.com/technet/scriptcenter
>
> > > > > > > > /resources/qanda/jan05/hey0107.mspx
>
> > > > > > > > Vinson
>
> > > > > > > > "consultmac2" wrote:
> > > > > > > > > Vinson,
>
> > > > > > > > > Thanks! However, I can't tell which issue you are especially
> > > > > > > > > recommending since the URL was cut off. See below. Can you
> > > > > > > > > clarify?
>
> > > > > > > > > On Sep 10, 10:48 pm, Vinson <Vin....DeleteThis@discussions.microsoft..com> wrote:
> > > > > > > > > > I would suggest using WMI.
>
> ...
>
> read more »

Net Share !!!!

Thanks for the idea Marty. After hitting a roadblock again with the
WMI/perl code I was using, I was looking for a fresh idea.

Using something like:
net share shareName=c:\dirToShare
sure sounded attractive, but it didn't solve the problem completely by
itself.

Initially disappointed, I found that the Net share command created a
share without the 'Everyone' ACL, so my VMs could not access them.
However, when I added a call to the CACLS tool that Vinson suggested
earlier, I end up with a share that IS accessible just fine by my VMs.

Thanks!!!!!

(WMI/Perl code I was using:
sub processSharable{
my $dirtoshare = $_[0];
my $sharename = $_[1];

my $FILE_SHARE = 0;
#my $mynode = Win32::NodeName();
my $strComputer = '.';
my $MAXIMUM_CONNECTIONS = 25;

my $objWMIService = Win32::OLE->GetObject('winmgmts:\\\\' .
$strComputer . '\\root\\cimv2');

my $objNewShare = $objWMIService->Get('Win32_Share');

my $errReturn = $objNewShare->Create ($dirtoshare, $sharename,
$FILE_SHARE,
$MAXIMUM_CONNECTIONS, 'Public share for Fabrikam employees.');
}
)


On Sep 15, 9:29 pm, Marty K <mrma....TakeThisOut@attglobal.net> wrote:
> consultmac2 wrote:
> > I'm trying to find out how to define a file share on the fly
> > (assuming the capability is enabled) via a DOS (or other) command file/
> > script, or perhaps VB as a last resort.
>
> > I'd like to be able to take a user supplied directory on a local
> > drive and be able to temporarily (or perm) associate a file share with
> > it. I'm attempting to work with some compiled programs that I don't
> > have source code access to... that uses this technique to communicate
> > with spawned virtual machines (via virtual LAN).
>
> > Clues, or pointers?
>
> > Thanks
>
> Try the net share command from command prompt.
> you can create bat file to run as needed