Get mapped drives of remote user/computer

[ksmith247]

Following the advise of the Scripting Guys I have come up with the following that simply will not do what I want it to. I need to run a script against a remote computer and have it tell me the current drive mappings of the currently logged on user. In case any of you are wondering why someone would find this useful, here is an example. Users are calling me all the time asking for the "G" drive or the "T" drive. We have MANY login scripts and letters are reused depending on group membership (I didn't some up with it, just have to live with it). Anyway, the user says "I need the T drive like Jim-Bob has". So I need to know what T is mapped to on Jim-Bob's PC.

$readInput = InputBox("EnterComputer Name", "")

$objWMIService = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & $readInput & "\root\cimv2")
$colDrives = $objWMIService.ExecQuery("Select * From Win32_LogicalDisk Where DriveType = 4")

For $objDrive In $colDrives
    MsgBox(0, "", "Name: " & $objDrive.DeviceID & @CRLF & "Network Path: " & $objDrive.ProviderName & @CRLF)
Next

This works fine against my local PC. I am thinking that there may be some permission issues with pulling this type of information but according to the article, it should work. I can't make it work even when I am the person logged on the remote computer. Any ideas anyone?

In VBS format:

strComputer = WScript.Arguments(0)
     
     Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
     
     Set colDrives = objWMIService.ExecQuery _
         ("Select * From Win32_LogicalDisk Where DriveType = 4")
     
     For Each objDrive in colDrives
         Wscript.Echo " " & objDrive.DeviceID & " drive = " & objDrive.ProviderName
     Next

[PsaltyDS]

Following the advise of the Scripting Guys I have come up with the following that simply will not do what I want it to. I need to run a script against a remote computer and have it tell me the current drive mappings of the currently logged on user. In case any of you are wondering why someone would find this useful, here is an example. Users are calling me all the time asking for the "G" drive or the "T" drive. We have MANY login scripts and letters are reused depending on group membership (I didn't some up with it, just have to live with it). Anyway, the user says "I need the T drive like Jim-Bob has". So I need to know what T is mapped to on Jim-Bob's PC.

$readInput = InputBox("EnterComputer Name", "")

$objWMIService = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & $readInput & "\root\cimv2")
$colDrives = $objWMIService.ExecQuery("Select * From Win32_LogicalDisk Where DriveType = 4")

For $objDrive In $colDrives
    MsgBox(0, "", "Name: " & $objDrive.DeviceID & @CRLF & "Network Path: " & $objDrive.ProviderName & @CRLF)
Next

This works fine against my local PC. I am thinking that there may be some permission issues with pulling this type of information but according to the article, it should work. I can't make it work even when I am the person logged on the remote computer. Any ideas anyone?

In VBS format:

strComputer = WScript.Arguments(0)
     
     Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
     
     Set colDrives = objWMIService.ExecQuery _
         ("Select * From Win32_LogicalDisk Where DriveType = 4")
     
     For Each objDrive in colDrives
         Wscript.Echo " " & objDrive.DeviceID & " drive = " & objDrive.ProviderName
     Next

Remotely connecting to a computer does not give you access to the environment of that computer's local user. You need that user to run your script in their own environment. Post it on a share everyone can see and have "Jim-Bob" run it. He can report the results back, or the script can log the results for you to somewhere "Jim-Bob" has write permissions.

[ksmith247]

Remotely connecting to a computer does not give you access to the environment of that computer's local user. You need that user to run your script in their own environment. Post it on a share everyone can see and have "Jim-Bob" run it. He can report the results back, or the script can log the results for you to somewhere "Jim-Bob" has write permissions.

Yea... I was really hoping that someone would know what bit to flip to make this work. We kicked around the idea of writing back to a log file but I thought I would post the question first. Thanks.