none
Could not start PsExec service on target machine. Access is denied. RRS feed

  • Question

  • Hi,

    I am trying to execute psexec command to remote machine.

    My command is

    psexec -u domain\user -p password \\machineName -c abc.bat

    I am trying from windows 7(64 bit)  machine. The remote machines are xp and windows 7(32 and 64 bit).

    In XP machines, it is working and also in some windows 7 machines. But in some windows 7 machines it give message-

    "Could not start PsExec service on target machine.

    Access is denied."

     

    If I try to execute psexec command from XP machines, it works to all machines.

    Suddenly what happen I do not know but one of the windows 7 machine( where psexec was not starting) , psexec started. but not in other machines.

    Now I am very much confuse here exactly what happen. and what is the issue.

    Please help. It urgent.

    Thanks.

    Tuesday, November 1, 2011 7:45 AM

Answers

  • Hi,

     

    When opening the Command Prompt, please right click it and run as Administrator. Meanwhile, make sure the user has administrator privileges on target PC. If the issue persists, try to disable UAC on both sides.

     

    As far as I know the Security Level on Windows 7 is higher than the level on Windows XP.  Therefore, 'psexec' works to all machines.

     

    Best Regards,

    Niki


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, November 3, 2011 8:29 AM
    Moderator
  • Hi,

    I had exacly the same issue today, only that I had many servers (2003, 2008 nad 2008 R2)

    Run command exacly as yours, from W7 SP1 and a elevated command window.

    It worked on 80% of the servers but on some it didn't work, I investigated it closer and found that all Server 2008 R2 rejected my calls in security log - with my login name from W7, not domain\user from the command.

    I loged in to my workstation with domain\Administrator and now the command was acceptet by all 200 servers without any problem.

    Hope this can help you in your investigation, it solved my issue.

     

    regards.

    Monday, November 7, 2011 3:48 PM

All replies

  • Hi,

     

    When opening the Command Prompt, please right click it and run as Administrator. Meanwhile, make sure the user has administrator privileges on target PC. If the issue persists, try to disable UAC on both sides.

     

    As far as I know the Security Level on Windows 7 is higher than the level on Windows XP.  Therefore, 'psexec' works to all machines.

     

    Best Regards,

    Niki


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, November 3, 2011 8:29 AM
    Moderator
  • Hi,

    I had exacly the same issue today, only that I had many servers (2003, 2008 nad 2008 R2)

    Run command exacly as yours, from W7 SP1 and a elevated command window.

    It worked on 80% of the servers but on some it didn't work, I investigated it closer and found that all Server 2008 R2 rejected my calls in security log - with my login name from W7, not domain\user from the command.

    I loged in to my workstation with domain\Administrator and now the command was acceptet by all 200 servers without any problem.

    Hope this can help you in your investigation, it solved my issue.

     

    regards.

    Monday, November 7, 2011 3:48 PM
  • It's not going to work with UAC enabled for the account on the target machine.

     

    • Proposed as answer by ashutosh.iddya Tuesday, March 25, 2014 10:50 PM
    Monday, November 7, 2011 7:46 PM
  • JS2010 I don't believe that is true.

    All machines in my enviroment have UAC turned on and no user has Admin rights to the machine and I can access all machines.

    The solution is the one provided by Niki Han

    Even though you stating which user account to execute the command on the remote system it excutes the psexec command as the user that opened the command window.  Right-clicking on cmd and hitting run as administrator then using the string with -u and specifying a user with admin rights to the machines you are attached to should work 90% or more of the time.  I have come accross a few computers that even this didn't work and those machines actually had system errors that we had to fix.

    Thanks

    Sean


    MCTS: Windows 7
    Tuesday, November 8, 2011 12:14 AM
  • Shrug.  Even if I try to use a remote account in the Administrators group, psexec will say 'Access is denied.'  I would have to enable the remote literal 'Administrator' account to use psexec on it.  But I don't use active directory, and UAC is at the default settings.  Maybe there's some other policy I didn't change.  The machine I'm launching psexec from is also Windows 2003.

     

     


    • Edited by JS2010 Tuesday, November 8, 2011 3:50 PM
    Tuesday, November 8, 2011 3:48 PM
  • Running psexec from an XP/Win2k3 PC against a Win7/Win2K8 target will work fine if you download Ver. 1.98 of PsExec with the new "-h" param.  Unfortunately, it seems that running PsExec from a Win7/Win2K8 machine against a Win7/Win2K8 target, regardless of the "-u" and "-p" params on the PsExec command-line, those params are ignored and PsExec is being executed remotely with whatever user credentials I happen to be logged in locally with.

    I confirmed this by logging in locally on a Win7 PC with an account that has local admin privs on the remote Win2K8 target and I didn't even need to include the -u or -p params to successfully start the PsExec service on the remote system.  The -u and -p params are totally ignored. 

    The only solution anyone seems to be offering is to use the "Runas" command to execute PsExec and forget the -u -p params. Unfortunately, Runas won't accept a password param and I use it iteratively in my script to connect to - in some cases - 60 different systems. Typing in the password 60 times in a row is a real bummer and using the Runas /savecred param is just plain frightening.

    Hopefully, someone has a better solution.

    • Proposed as answer by MadMonk99 Thursday, June 7, 2012 2:28 PM
    Tuesday, January 10, 2012 2:32 AM
  • any solution about it ? thx

    Should "Hi", "Thanks" and taglines and salutations be removed from posts? http://meta.stackoverflow.com/questions/2950/should-hi-thanks-and-taglines-and-salutations-be-removed-from-posts

    Wednesday, February 8, 2012 4:04 PM
  • Confirmed...do a "run as" for your command prompt (with the account you will need on the remote system) and use the -h param for psexec and don't even bother with the -u and -p params. 
    Thursday, June 7, 2012 2:30 PM
  • I know You already have your answer, but you should also try -h key.

    For example:

    psexec -u Domain\Username -p password \\targetmachine -c -h program.bat

    Wednesday, June 20, 2012 1:59 PM
  • Using the -h parameter when running commands against Windows 7 worked for me.  I was using an old version of PSExec and was getting "access is denied" on numerous Windows 7 computers.  I switched to the new version, added the -h to my command and it started working.  When I downloaded the new version, the -h switch wasn't listed on the webpage in the description.

    Wouldn't have known about it except for the post by Brad.

    Thanks.

    Saturday, September 22, 2012 2:18 PM
  • Running psexec from an XP/Win2k3 PC against a Win7/Win2K8 target will work fine if you download Ver. 1.98 of PsExec with the new "-h" param.  Unfortunately, it seems that running PsExec from a Win7/Win2K8 machine against a Win7/Win2K8 target, regardless of the "-u" and "-p" params on the PsExec command-line, those params are ignored and PsExec is being executed remotely with whatever user credentials I happen to be logged in locally with.

    I confirmed this by logging in locally on a Win7 PC with an account that has local admin privs on the remote Win2K8 target and I didn't even need to include the -u or -p params to successfully start the PsExec service on the remote system.  The -u and -p params are totally ignored. 

    The only solution anyone seems to be offering is to use the "Runas" command to execute PsExec and forget the -u -p params. Unfortunately, Runas won't accept a password param and I use it iteratively in my script to connect to - in some cases - 60 different systems. Typing in the password 60 times in a row is a real bummer and using the Runas /savecred param is just plain frightening.

    Hopefully, someone has a better solution.

    Instead of using /savecred I save the password to a temp file and then redirect that to input of runas, like this:

    echo "password" > pwd
    runas /env /netonly /user:Domain\username "psexec.exe cmd.exe" < pwd
    del pwd

    Thursday, October 25, 2012 3:45 PM
  • Or just:

    echo password | runas /env /netonly /user:Domain\username "psexec.exe cmd.exe"

    Friday, November 16, 2012 12:07 AM
  • It does work!

    After I set the user as administrator at target machine, everything's work!
    Thousand thanks!

    • Proposed as answer by arSZEE Thursday, November 29, 2012 3:45 AM
    • Unproposed as answer by arSZEE Thursday, November 29, 2012 3:45 AM
    Thursday, November 29, 2012 3:45 AM
  • Don't forget to check your Anti-virus which frequently blocks several of the PStools.
    • Proposed as answer by Rogues Tuesday, February 26, 2013 6:36 PM
    Tuesday, February 26, 2013 6:36 PM
  • I had exactly the same issue and with this Workaround (runas) it worked well. But earlier (with an old Group Policy) PSEXEC worked without this Workaround.

    Therefore (and because the customer wan't it), I figured out which Group Policy-Setting is responsible for the problem:

    After a long time of testing I found the solution: I had to block the following Firewall-Policys:

    • Remote Service Management (RPC)
    • Remote Service Management (RPC-EPMAP)

    Best Regards Fabian

    Wednesday, October 2, 2013 12:36 PM
  • I have tried ALL of these solutions and NONE of them work.  Now I have lost weeks worth of work getting this network set up to run remote jobs, all because I had to reload ONE Windows 7 machine and now it's suddenly decided to deny access to EVERYTHING despite being configured exactly as it was before.  I've even gone as far as disabling the firewall completely and it still won't work.

    Thanks for nothing Microsoft.

    Thursday, January 30, 2014 8:46 AM
  • It took me hours to find a working way to PsExec between 2 Windows 7 Computers with non-Admin user starting PsExec ... Disabling UAC (EnableLUA=0, ConsentPromptBehaviorAdmin=0, LocalAccountTokenFilterPolicy=1) did not work, turning off the Firewalls did not work...

    Here i found the working way - thanks JelmerS:
    (Info from http://serverfault.com/questions/489822/psexec-is-not-connecting-to-machine-using-supplied-username-and-password/489845)

    This is because psexec still tries to access the ADMIN$ share with your local credentials, before executing your command as another user. According to this thread, you can cache credentials before executing psexec:
    cmdkey.exe /add:MACHINE_NAME_HERE /user:MACHINE_NAME_HERE\Administrator /pass:PASSWORD_HERE
    psexec.exe \\MACHINE_NAME_HERE -i notepad
    cmdkey.exe /delete:MACHINE_NAME_HERE

    Best regards, Peter

    • Proposed as answer by zSandman Wednesday, March 26, 2014 2:48 PM
    Wednesday, February 26, 2014 3:36 PM
  • Peters method worked for me.  It solved the access denied issue. It turns out our group policy which turns of the firewall domain profile but leaves on the public and private firewall profile was causing the access denied, but even when I turned off the firewall service I got an error telling me that the Admin$ share did not exist, yet it did.

    Using the local administrator credentials as Peter indicated using the cmdkey to store the credentials solved both issues.  

    Thank you Peter!

    Friday, April 4, 2014 4:37 PM
  • I know may be it's a little late but I fixed the problem like this:

    runas /user:Administrator /savecred "psexec -u administrador -p xxpasswordxx \\machine net stop servicename"

    May me can be of help.

    Regards.

    Christian


    Monday, March 16, 2015 7:35 PM
  • It took me hours to find a working way to PsExec between 2 Windows 7 Computers with non-Admin user starting PsExec ... Disabling UAC (EnableLUA=0, ConsentPromptBehaviorAdmin=0, LocalAccountTokenFilterPolicy=1) did not work, turning off the Firewalls did not work...

    Here i found the working way - thanks JelmerS:
    (Info from http://serverfault.com/questions/489822/psexec-is-not-connecting-to-machine-using-supplied-username-and-password/489845)

    This is because psexec still tries to access the ADMIN$ share with your local credentials, before executing your command as another user. According to this thread, you can cache credentials before executing psexec:
    cmdkey.exe /add:MACHINE_NAME_HERE /user:MACHINE_NAME_HERE\Administrator /pass:PASSWORD_HERE
    psexec.exe \\MACHINE_NAME_HERE -i notepad
    cmdkey.exe /delete:MACHINE_NAME_HERE

    Best regards, Peter

    Awesome! Thank you for this one. I created an HTA application to allow non-Administrator users to start or stop certain services on an application server. There is also a WMI-driven GUI to view the service states. I do not want to give them local Admin on their computers or the servers. WMI worked, but they wanted to see the entire start-up process (huge CMD files on server, gotta love IBM's Java stuff....), and PsExec does that. It worked for me being an admin, but a standard user got access denied. The CmdKey idea worked!!!

    objShell.Run "CmdKey /Add:ServerName /User:DOMAIN\serviceAccount /Pass:p@$$w0rd!",0,True

    objShell.Run "PsExec \\ServerName /H /S /U DOMAIN\serviceAccount /Pass:P@$$w0rd! C:\DIR\start.cmd",1,True

    objShell.Run "CmdKey /Delete:ServerName",0,True

    Voila!!!!


    • Edited by Mako-Wish Friday, October 16, 2015 4:16 PM
    Friday, October 16, 2015 4:15 PM
  • if you don't run with admin rights, it will throw the error. It is always recommended to psexec commands with elevated access from command line - http://www.nuttycloud.com/run-ipconfig-remotely-using-psexec/

    • Edited by mv3499 Thursday, May 19, 2016 8:01 AM
    Thursday, May 19, 2016 8:01 AM