DiskScan Issue
Keywords: DiskScan network mapped drive drives GetDriveType
Question 1:
I recently needed to find an unused drive letter so I could mount a drive. I tried using "DiskScan(0)" which looked
like it would do what I wanted. However, it seems that it will return network drive letters that are assigned but
are listed as "Unavailable" with Net Use. Even though these letters are considered as unavailable, they are still assigned
and I will get an error if I try to mount using these letters. Is there a better method that I can use to get a drive letter
I can really use?? Am I using the wrong function??
I am running XP with SP2 and current fixes. WinBatch is 2007C.
Answer 1:
Although DiskScan(0) *very often* works for this purpose, it is not foolproof, depending on your system configuration. I
could not find another API that could do exactly what you need. At this time I propose simply attempting the wntAddDrive
operation, and using ErrorMode to recover from a possible failure, in which case try again with the next drive letter
in the list.
I've talked to the developers about possibly making DiskScan smarter so that DiskScan(0) would only return a list of
usable drive letters and having a new "Other" category forthe other drive letters that are unusable. That would make
a lot of people happy.
****** UPDATE ******
As of 2007D we added a new request # to DiskScan:
Request Returns
------- -------
32 list of remembered (persistent) but currently non-connected drives.
DiskScan(0) no longer returns drives that are remembered (persistent) but not currently connected. These are now returned
by DiskSccan(32).
Question 2:
DiskScan(4) is returning a blank string on Windows Vista, even though Windows Explorer shows the network drive mappings.
Answer 2:
Thank you for notifying us about the problem on Windows Vista. We are able to reproduce this.
ISSUE: When running as an Administrator on Vista, the user has two contexts: the limited user context, and the administrator context.
When you map drives in Windows Explorer, they are added only for the limited user context. Thus when the script runs in
the administrative context, no mapped drives 'seen' by the script. WBT files run with user elevation 'HighestAvilable', which means
when running under an Administrator account the script is running in the context of the administrator NOT the user.
OPTIONS:
- Turn off UAC.
- Perhaps map the drives under the administrator context in the first place.
- Compile script using the AsInvoker manifest ( tells the script to run within the user level context ).
- You can set this Registry value and you will get access to those drives from both 'integrity' levels.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections =(dword)1
- Administrative users should map network drives under the limited user token. This mapping is
accomplished by scheduling the script to run using the task scheduler. The task scheduler launches the script
under the administrative full token, thereby allowing Windows Explorer, other limited token processes, and
the elevated token process to view the mapped network drives.
Reference: See "Group Policy Scripts can fail due to User Account Control" section of this doc:
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
- NOTE: Strangely... a single call to AskFileName causes all of these functions to properly locate all of the mapped drives. (You must
then Reboot to reproduce issue).
It would seem that many other functions are also affected by this issue.
Most any function that references the mapped drive: DirChange, FileOpen, FileExist, FileItemize, wntGetCon, etc.
Resources:
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx
https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=939697&SiteID=1
Article ID: W17291
File Created: 2007:10:24:13:46:44
Last Updated: 2007:10:24:13:46:44