Answered by:
Could not start PsExec service on target machine. Access is denied.

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.
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.- Proposed as answer by Sean Mallonee Tuesday, November 8, 2011 12:14 AM
- Marked as answer by Niki HanModerator Monday, November 14, 2011 1:02 PM
-
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.
- Marked as answer by Niki HanModerator Monday, November 14, 2011 1:01 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.- Proposed as answer by Sean Mallonee Tuesday, November 8, 2011 12:14 AM
- Marked as answer by Niki HanModerator Monday, November 14, 2011 1:02 PM
-
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.
- Marked as answer by Niki HanModerator Monday, November 14, 2011 1:01 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
-
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 -
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
-
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
-
-
-
-
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.
-
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
-
-
-
-
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
-
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.
-
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_HEREBest regards, Peter
- Proposed as answer by zSandman Wednesday, March 26, 2014 2:48 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!
-
-
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_HEREBest 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
-
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