getting around Psexec access denied errors when executing file on network share

psexec is a utility for remotely executing files on a networked computer. there is a limitation with it however, whereas you can not launch an executable located on a network share. you will note the same behavior if you connect to a telnet session, and try to connect to a network share, no matter which user rights the user you connected to has on the domain.

Here is an example whereas i wanted to force a logon script i set up in group policy to perform some disk maintenance:

U:>psexec \andys-pc "\serverSYSVOLdomain.comscriptsschedule_defrags.bat"

PsExec v1.94 - Execute processes remotely
Copyright (C) 2001-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

Starting \serverSYSVOLdomain.comscriptsschedule_defrags.bat on andys-pc

Access is denied.
\serverSYSVOLdomain.comscriptsschedule_defrags.bat exited on andys with error pre 1.

a very simple workaround is to eliminate the psexec with the old school command “at” to schedule the task a minute or two ahead of the current time:

U:>at \ANDYS 11:20 \serverSYSVOLdomain.comscriptsschedule_defrags.bat
Added a new job with job ID = 1

or if you are like me, and want to force the entire domain to run an executable from a network location, for example, a logon script:

U:>for /f %n in ('net view ^| find "\" ^| gawk "{print $1}' ^| grep -i -v -e "server1" -e "server2" -e "server3" ') do at %n 11:30 \serverSYSVOLdomain.comscriptsschedule_defrags.bat 

note: i used gawk and grep in there, because i love linux utils ported to windows. you can achieve similar results by using a series of

 ^| find /v "server1" 

for excluding the systems you want, but i do not know of a replacement for the gawk portion of that statement.
however, this should output:

U:>at \ANDYS 11:30 "\serverSYSVOLdomain.com.comscriptsschedule_defrags.bat"
Added a new job with job ID = 1

U:>at \APP-SRV 11:30 "\serverSYSVOLdomain.com.comscriptsschedule_defrags.bat"
Added a new job with job ID = 1

U:>at \BEPPEL 11:30 "\serverSYSVOLdomain.com.comscriptsschedule_defrags.bat"
Added a new job with job ID = 1

U:>at \CHRISG 11:30 "\serverSYSVOLdomain.com.comscriptsschedule_defrags.bat"
Added a new job with job ID = 1

and so forth, for each computer in the domain…

your welcome.

Did you like this? Share it:
This entry was posted in Tips and tricks and tagged , . Bookmark the permalink.

4 Responses to getting around Psexec access denied errors when executing file on network share

  1. KM says:

    This is a clever workaround. It might be that psexec has added new functionality since your post, but I was able overcome the access denied errors by including the user domain credentials, thus:
    psexec \REMOTEPC -u DOMAINadminuser -p “\SERVERsharecommand to run.cmd”

    Remote system is running Win7 in my case.
    HTH.

  2. Jeff says:

    I found another reason PSEXEC (and other PS tools) fail – If something (…say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an “Access is Denied” error, PSLIST will give the error “Processor performance object not found on ” and you’ll be left in the dark as to the reason.

    You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there’s no indication that file(s) or folder(s) being hidden is the reason.

    I’ll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim – just thought I’d put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.

  3. Sprever says:

    Where do I get the old school command “at”? Been searching and could find any.

Leave a Reply

Your email address will not be published. Required fields are marked *