Pls Explain Path in this MSDN example

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Starting with
http://msdn2.microsoft.com/en-us/library/system.management.managementscope.aspx

' Make a connection to a remote computer.
' Replace the "FullComputerName" section of the
' string "\\FullComputerName\root\cimv2" with
' the full computer name or IP address of the
' remote computer.
Dim scope As ManagementScope
scope = New ManagementScope( _
"\\FullComputerName\root\cimv2")
scope.Connect()

Why is there a cimV2 ? IfI can manually map to \\MyServer\MyShare - and I
can PING myServer ( but not myServer\mySahre ) and the IP address is for
MyShare.

How am I to map | connect the drive ? If I use \\MyServer\MyShare I get RPC
server not available. -Can someone explain what should be the parameters that
has really tested it ? Thanks
 
Hi Andrew,

This path is not, well, a path to a network share. Everything behind the
computer name or the IP address followed by the slash is a WMI-specific
notation to designate a specific WMI object or collection on the remote
machine. Hence, in the MSDN example you're referring to, just specify the
correct computer name and leave "\root\cimv2" unchanged.

Speaking of possible troubleshooting, you should rather look into
permissions - if the account under which your sample runs does not have
administrative privileges on the remote machine, access might be denied.
 
Dmytro, Thanks for clarifying the mysterious use of \root\cimv2 - I am
deeply puzzled over the lack of enterprise .NET support as I see it. Large
companies like the one I work for ' rent ' out ComputerName\ShareName. We
can map to these drives if we have permission. And then move files as needed.
With VB 6 the object funcionality is cleanly exposed with COM via the Window
Scripting Host. While its true I can make an Interop Assembly just to do
this function, I think that both WSH and WMI have common cores ( both COM ).
Is there no other way ?

Lastly Is there a way to let MS know that building out a whole class file
encapsulating WIN 32 or making interop asseblies just to do this function is
- silly ! - when the same capability is exposed nicely for a different
process ( exe ) with this :
System.Diagnostics.Process.Start(filename,username, password, domain) ?
 
Back
Top