Network Drives (Word VBA)

Topic

New Reply

Hi all,

I am wondering whether there is a way (using Word VBA) to check to see what network drives the user has access to. Either the drive letter or the share name (preferable). I’d like to check this out for the user and then I plan to list it in a combobox.

Thanks!

Reply | Quote

Replies

Not what you asked, but is Don’s post using BrowseForFolder, and one of the applicable shellspecialfolderconstants of use?

Reply | Quote

Not what you asked, but is Don’s post using BrowseForFolder, and one of the applicable shellspecialfolderconstants of use?

Reply | Quote

I think we’ve had a post on this in the past few months, so try a search here. It’s probably repeating myself to say: the FileSystemObject has a Drives collection which will include mapped drive letters.

Reply | Quote

I think we’ve had a post on this in the past few months, so try a search here. It’s probably repeating myself to say: the FileSystemObject has a Drives collection which will include mapped drive letters.

Reply | Quote

As noted in previous reply by jscher2000, the easy way to do this is use Scripting FileSystemObject (FSO) – just loop thru the Drives collection, test the DriveType and ShareName properties for each Drive object found. If DriveType is Remote (constant value 3) then it’s a network drive. If network drive, ShareName property returns UNC path (assumes are connected to network). As alternative to FSO, you can use Windows API functions to do this. For sample, see attached text file, exported code module. GetLogicalDrives function returns all logical drives as a bitmask Long integer value. GetDriveType function gets drive type – note the Windows constants are not same as those used by FSO; user-defined GetDriveTypeString function translates return value to a text string. WNetGetConnection is used to get UNC path. Run EnumDrives() sub to list all drives found, drive type, UNC path (if not network drive, drive letter displayed).

For FSO code examples, recommend search, many examples have been previously posted.

HTH

Reply | Quote

For the record, FSO version of routine to enumerate drives:

Public Sub EnumDrivesFSO()

Dim fso As FileSystemObject
Dim drv As Scripting.Drive

Set fso = New FileSystemObject

For Each drv In fso.Drives
Debug.Print drv.DriveLetter & ": " & _
GetDriveTypeStringFSO(drv.DriveType), _
"UNC Path: " & drv.ShareName
Next drv

Set fso = Nothing
Set drv = Nothing

End Sub

User-defined function to return text string for drive type:

Private Function GetDriveTypeStringFSO _
(ByVal lDriveType As Scripting.DriveTypeConst) As String

Select Case lDriveType
Case Removable '1
GetDriveTypeStringFSO = "Removable"
Case Fixed '2
GetDriveTypeStringFSO = "Fixed"
Case Remote '3
GetDriveTypeStringFSO = "Network"
Case CDRom '4
GetDriveTypeStringFSO = "CD"
Case RamDisk '5
GetDriveTypeStringFSO = "RAM"
Case Unknown '0
GetDriveTypeStringFSO = "Unknown"
Case Else
GetDriveTypeStringFSO = "Unknown"
End Select

End Function

The above requires reference set to MS Scripting Runtime library. If this library not available, API methods can be used instead. On network system at work both API & FSO versions of EnumDrives() procedure returned correct results.

HTH

Reply | Quote

Is this scripting library the same VBScript that’s the culprit in so many attacks? IIRC it’s been recommended for at least a couple of years that it be removed/deactivated unless you use it. Here, of course, you’re using it (if it’s the same one) but how would the security advice affect things when you distribute the app?

Perhaps the API routines would be more reliable?

Reply | Quote

No, I think you’re getting the terminology mixed up. VBScript (official name: “Microsoft

Reply | Quote

Thanks for clarifying the difference. It doesn’t sound like I’d be bypassing security policies-our policy is to disable VBScript to block the malware, not to block our capabilities-although it very effectively does that too. I’ll check on this scripting library as it’s either nothing I’ve ever heard of before or when I’ve heard of it in the past I’ve always confused it with VBScript. Trust Microsoft.

Reply | Quote

There are a lot of pieces to the puzzle. There are two script execution engines (cscript.exe, wscript.exe) –VBA doesn’t require these — and a few code libraries (e.g., scrrun.dll, vbscript.dll). There are many ways to block scripts from running, so you’ll probably have to do some testing to see how it has impacted your environment.

Reply | Quote

Whew! Thanks-didn’t realize there were so many pieces. I’ll have to check it out but I believe that all they do here is delete/disable wscript.exe-but it’s been a year or two since I was last involved in setting up the PC’s. Now I’m more involved in the programming.

Reply | Quote

Whew! Thanks-didn’t realize there were so many pieces. I’ll have to check it out but I believe that all they do here is delete/disable wscript.exe-but it’s been a year or two since I was last involved in setting up the PC’s. Now I’m more involved in the programming.

Reply | Quote

Thanks for clarifying the difference. It doesn’t sound like I’d be bypassing security policies-our policy is to disable VBScript to block the malware, not to block our capabilities-although it very effectively does that too. I’ll check on this scripting library as it’s either nothing I’ve ever heard of before or when I’ve heard of it in the past I’ve always confused it with VBScript. Trust Microsoft.

Reply | Quote

No, I think you’re getting the terminology mixed up. VBScript (official name: “Microsoft

Reply | Quote

Is this scripting library the same VBScript that’s the culprit in so many attacks? IIRC it’s been recommended for at least a couple of years that it be removed/deactivated unless you use it. Here, of course, you’re using it (if it’s the same one) but how would the security advice affect things when you distribute the app?

Perhaps the API routines would be more reliable?

Reply | Quote

For the record, FSO version of routine to enumerate drives:

Public Sub EnumDrivesFSO()

Dim fso As FileSystemObject
Dim drv As Scripting.Drive

Set fso = New FileSystemObject

For Each drv In fso.Drives
Debug.Print drv.DriveLetter & ": " & _
GetDriveTypeStringFSO(drv.DriveType), _
"UNC Path: " & drv.ShareName
Next drv

Set fso = Nothing
Set drv = Nothing

End Sub

User-defined function to return text string for drive type:

Private Function GetDriveTypeStringFSO _
(ByVal lDriveType As Scripting.DriveTypeConst) As String

Select Case lDriveType
Case Removable '1
GetDriveTypeStringFSO = "Removable"
Case Fixed '2
GetDriveTypeStringFSO = "Fixed"
Case Remote '3
GetDriveTypeStringFSO = "Network"
Case CDRom '4
GetDriveTypeStringFSO = "CD"
Case RamDisk '5
GetDriveTypeStringFSO = "RAM"
Case Unknown '0
GetDriveTypeStringFSO = "Unknown"
Case Else
GetDriveTypeStringFSO = "Unknown"
End Select

End Function

The above requires reference set to MS Scripting Runtime library. If this library not available, API methods can be used instead. On network system at work both API & FSO versions of EnumDrives() procedure returned correct results.

HTH

Reply | Quote

As noted in previous reply by jscher2000, the easy way to do this is use Scripting FileSystemObject (FSO) – just loop thru the Drives collection, test the DriveType and ShareName properties for each Drive object found. If DriveType is Remote (constant value 3) then it’s a network drive. If network drive, ShareName property returns UNC path (assumes are connected to network). As alternative to FSO, you can use Windows API functions to do this. For sample, see attached text file, exported code module. GetLogicalDrives function returns all logical drives as a bitmask Long integer value. GetDriveType function gets drive type – note the Windows constants are not same as those used by FSO; user-defined GetDriveTypeString function translates return value to a text string. WNetGetConnection is used to get UNC path. Run EnumDrives() sub to list all drives found, drive type, UNC path (if not network drive, drive letter displayed).

For FSO code examples, recommend search, many examples have been previously posted.

HTH

Reply | Quote

Something like this:

Option Explicit

    Private Declare Function GetDriveType Lib "kernel32" Alias _
    "GetDriveTypeA" (ByVal sDrive As String) As Long

'        Const DRIVE_TYPE_UNDTERMINED = 0
'        Const DRIVE_ROOT_NOT_EXIST = 1
'        Const DRIVE_REMOVABLE = 2
'        Const DRIVE_FIXED = 3
'        Const DRIVE_REMOTE = 4
'        Const DRIVE_CDROM = 5
'        Const DRIVE_RAMDISK = 6

Sub ShowNetworkedDrives()
    Dim iCounter As Integer
    For iCounter = 65 To 90
        If GetDriveType(Chr(iCounter) & ":") = "4" Then
            msgbox "Drive " & Chr(iCounter) & " is a network drive"
        End If
    Next
End Sub

Reply | Quote

Something like this:

Option Explicit

    Private Declare Function GetDriveType Lib "kernel32" Alias _
    "GetDriveTypeA" (ByVal sDrive As String) As Long

'        Const DRIVE_TYPE_UNDTERMINED = 0
'        Const DRIVE_ROOT_NOT_EXIST = 1
'        Const DRIVE_REMOVABLE = 2
'        Const DRIVE_FIXED = 3
'        Const DRIVE_REMOTE = 4
'        Const DRIVE_CDROM = 5
'        Const DRIVE_RAMDISK = 6

Sub ShowNetworkedDrives()
    Dim iCounter As Integer
    For iCounter = 65 To 90
        If GetDriveType(Chr(iCounter) & ":") = "4" Then
            msgbox "Drive " & Chr(iCounter) & " is a network drive"
        End If
    Next
End Sub

Reply | Quote