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

Started by warren, July 19, 2013, 09:40:20 AM

Previous topic - Next topic

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.
Deana F.
Technical Support
Wilson WindowWare Inc.

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
; 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.
Deana F.
Technical Support
Wilson WindowWare Inc.

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.