Winbatch 2013A having problems with \\servername\c$\directory?

[warren]

Winbatch 2013A is having problems with enumerating \\servername\c$\directory
Windows 7

Yes I have admin access to this admin share
I have tried this with fileitemize, fileexist, fileopen, etc.

When I do a fileitemize it returns an empty list, even if there are files present
DRControl = "\\\myserver\d$\Winbatch"
message ("!", FileItemize ("%drcontrol%\*.*"))

Winbatch access to \\servername\sharename\directory to the same path works fine.
Accessing \\servername\c$\directory via windows explorer works fine.

Any ideas?

Thanks

[Deana]

Your UNC path has three leading slashes where there should only be two. Try changing \\\myserver\d$\Winbatch to \\myserver\d$\Winbatch

If this doesn't resolve your problem....Are you running compiled or interpreted. If compiled, what manifest settings are used? It might be best to provide some Debugtrace output. It will contain this type of information. Simply add DebugTrace(@on,"trace.txt") to the beginning of the script and inside any UDF, run it until the error or completion, then inspect the resulting trace file for clues as to the problem.

[warren]

Sorry that was a cut and paste typo.  :P

This does appear to work on some servers and admin shares. The win2008 server it is not working on looks like:

DRControl = "\\server1\f$\RevCS\ControlBackups"
message ("!", FileItemize ("%drcontrol%\*.*")) ; this does not work


DRControl = "\\server1\RevCS\ControlBackups" 
message ("!", FileItemize ("%drcontrol%\*.*")) ; this works

I updated to winbatch 2013b, same results.

Ideas?

[warren]

Ok, maybe this is the issue:

Does Winbatch use the security settings from the currently logged in user, or from the saved authenticated sessions in windows explorer?

In windows explorer I saved my ID / Password for the server on which I am trying to access the files through the admin share. The ID / Password is not the same as my desktop ID / Password.

[Deana]

This code can be used to list shares seen by the script:

Code (winbatch) Select Expand

; Load Appropriate Extender
AddExtender('wwwnt34i.dll',0,'wwwnt64i.dll')

list=wntShareList("\\server1\", 1 | 16, 0)
AskItemlist("List of shares",list, @TAB, @UNSORTED, @SINGLE)
Exit

Please provide the debugtrace output of your test script. It might contain a clue.

[ChuckC]

Also of interest...

Is UAC enabled on this system?

The O.P. states that administrative access/rights are present, but, what is the actual account being used to access the C$ share on this workstation?  Is it a domain account or a local account?  Is it the built-in Administrator account or a user account that has membership in the domain admins groups, local built-in administrators group, or just has a specific set of LSA privileges & rights granted to the account?

[warren]

Thank you for the script code.

Sure, UAC is enabled.

I think the issue was that windows explorer had a saved ID / Password (server admin) to access the server that did not match the ID password of the logged in user (normal user). The winnt dll apparently uses the currently logged in user rather than the windows explorer cached authentication.

Thanks,

-Warren.

[ChuckC]

With UAC enabled, the Windows Explorer runs using the restricted token and not the elevated token.  In this situation, that translates into the "saved ID / Password" information being associated with the restricted token as it is intimately related to the mapping of network device connections.  If your WinBatch script were to be executed using the elevated token, then by default it would not have access to the "saved ID / Password" information since the elevated token uses a table of network connections that is different from the table used by the restricted token.  The end result is that you would see this difference in behavior.