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

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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

  • Question
    Sign in to vote
    2
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    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

  • Question
    Sign in to vote
    2
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    7
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote
    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
    |
  • Question
    Sign in to vote
    1
    Sign in to vote
    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    Or just:

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

    Friday, November 16, 2012 12:07 AM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    1
    Sign in to vote
    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    4
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    |
  • Question
    Sign in to vote
    0
    Sign in to vote
    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
    |