_FileListToArray returning error code when running as administrator

[anthonyjr2]

Hi,

 

I have a script that is getting all files in a directory on a network share, and listing them so I can move them to another folder. The script works fine normally, however I need to run this script as administrator, and for some reason _FileListToArray() returns an error code of 1 when the script is running in admin mode. Can't seem to find a reason for this online, anyone know why this would be happening?

 

$ftpList = _FileListToArray("\\dev-pc\Get\", "*.txt", 1) ;get list of all files in share directory (files only flag)
    If @error Then
        logToFile("Error getting file list, err: " & @error)
    EndIf
    For $fName In $ftpList
        FileMove("\\dev-pc\Get\" & $fName, "\\dev-pc\Get\Archive\" & $fName) ;loop through files (should only be 1) and move to archive in share
        If @error Then
            logToFile("Error moving existing file " & $fName & " to archive")
        EndIf
        logToFile("Moved file " & $fName & " to archive")
    Next

Thanks for any advice

[Jos]

You are using a UNC connection to the directory you are trying to list and likely the ADMIN account of the laptop doesn't have access to that share.
Try making a Mapped drive to a drive letter and use that mapped drive in the Elevated script.

[anthonyjr2]

4 minutes ago, Jos said:

You are using a UNC connection to the directory you are trying to list and likely the ADMIN account of the laptop doesn't have access to that share.
Try making a Mapped drive to a drive letter and use that mapped drive in the Elevated script.

Everything I saw online was saying to not use a mapped drive, as UNC paths would be ideal for admin scripts. The share has access set to "Everyone" so I don't think it would have been a permissions issue.

 

However, I did some further googling and turns out adding EnableLinkedConnections as a key to the registry in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" and restarting the PC fixed the problem. Something to do with allowing access to network locations in elevated processes. Thanks for the tip though, I will try mapping drives in the future if I run into other problems.

[Jos]

I actually think you are right about using a UNC instead of mapped drive, and think I mixed them up in my mind.

[rudi]

as Jos mentioned already scripts, that run UAC elevated are executed in a different security context (not necessary a different user)

 

You can see the difference by opening two CMD.EXE command prompt boxes.

 

Commit the command "net use" in both of them, and you will see the differences.

 

For your purpose the use of UNC paths is to be preferred over mapped drives, as mapped drives have to be "mapped also in the UAC elevated context". If t he user is the same, and the user has access to your UNC path, then the access will be available usually in the UAC elevated runspace as well.