Windows 10 PsExec localhost
The following command generally works fine on Windows 7 and Windows 10:
psexec \machine -u username -p password -h -c -f script.bat
However, on Windows 10 when 'machine' is the localhost, I receive the error below:
Could not start PSEXESVC on localhost:
Access is denied.
The error message goes away if I run the command at an elevated prompt. Is there anyway to avoid this? What specifically is causing the issue on the local machine on Windows 10?
windows-10 psexec
add a comment |
The following command generally works fine on Windows 7 and Windows 10:
psexec \machine -u username -p password -h -c -f script.bat
However, on Windows 10 when 'machine' is the localhost, I receive the error below:
Could not start PSEXESVC on localhost:
Access is denied.
The error message goes away if I run the command at an elevated prompt. Is there anyway to avoid this? What specifically is causing the issue on the local machine on Windows 10?
windows-10 psexec
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37
add a comment |
The following command generally works fine on Windows 7 and Windows 10:
psexec \machine -u username -p password -h -c -f script.bat
However, on Windows 10 when 'machine' is the localhost, I receive the error below:
Could not start PSEXESVC on localhost:
Access is denied.
The error message goes away if I run the command at an elevated prompt. Is there anyway to avoid this? What specifically is causing the issue on the local machine on Windows 10?
windows-10 psexec
The following command generally works fine on Windows 7 and Windows 10:
psexec \machine -u username -p password -h -c -f script.bat
However, on Windows 10 when 'machine' is the localhost, I receive the error below:
Could not start PSEXESVC on localhost:
Access is denied.
The error message goes away if I run the command at an elevated prompt. Is there anyway to avoid this? What specifically is causing the issue on the local machine on Windows 10?
windows-10 psexec
windows-10 psexec
edited Jul 15 '16 at 11:02
asked Jul 15 '16 at 9:29
Franzl
11613
11613
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37
add a comment |
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37
add a comment |
1 Answer
1
active
oldest
votes
psexec \machine -u USERNAMR -p PASSWORD -h -c -f script.bat
or just omit -p PASSWORD to securely prompt for password:
psexec \machine -u USERNAMR -h -c -f script.bat
-h
is to "run with the account's elevated token, if available". So, if you don't run your CMD with elevated privileges, no elevated token is available! There's nothing wrong with Windows. It needs either an elevated token, or elevated credentials to gain that token.
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC andLocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.
– NetwOrchestration
Jul 15 '16 at 12:45
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1101168%2fwindows-10-psexec-localhost%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
psexec \machine -u USERNAMR -p PASSWORD -h -c -f script.bat
or just omit -p PASSWORD to securely prompt for password:
psexec \machine -u USERNAMR -h -c -f script.bat
-h
is to "run with the account's elevated token, if available". So, if you don't run your CMD with elevated privileges, no elevated token is available! There's nothing wrong with Windows. It needs either an elevated token, or elevated credentials to gain that token.
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC andLocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.
– NetwOrchestration
Jul 15 '16 at 12:45
add a comment |
psexec \machine -u USERNAMR -p PASSWORD -h -c -f script.bat
or just omit -p PASSWORD to securely prompt for password:
psexec \machine -u USERNAMR -h -c -f script.bat
-h
is to "run with the account's elevated token, if available". So, if you don't run your CMD with elevated privileges, no elevated token is available! There's nothing wrong with Windows. It needs either an elevated token, or elevated credentials to gain that token.
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC andLocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.
– NetwOrchestration
Jul 15 '16 at 12:45
add a comment |
psexec \machine -u USERNAMR -p PASSWORD -h -c -f script.bat
or just omit -p PASSWORD to securely prompt for password:
psexec \machine -u USERNAMR -h -c -f script.bat
-h
is to "run with the account's elevated token, if available". So, if you don't run your CMD with elevated privileges, no elevated token is available! There's nothing wrong with Windows. It needs either an elevated token, or elevated credentials to gain that token.
psexec \machine -u USERNAMR -p PASSWORD -h -c -f script.bat
or just omit -p PASSWORD to securely prompt for password:
psexec \machine -u USERNAMR -h -c -f script.bat
-h
is to "run with the account's elevated token, if available". So, if you don't run your CMD with elevated privileges, no elevated token is available! There's nothing wrong with Windows. It needs either an elevated token, or elevated credentials to gain that token.
edited Jul 15 '16 at 10:50
answered Jul 15 '16 at 10:45
NetwOrchestration
1,89211127
1,89211127
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC andLocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.
– NetwOrchestration
Jul 15 '16 at 12:45
add a comment |
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC andLocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.
– NetwOrchestration
Jul 15 '16 at 12:45
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
On the first point, I was already entering the password, so I've amended my question to reflect that. On your second point, why does Windows not require an elevated token when running the script on a remote machine?
– Franzl
Jul 15 '16 at 11:05
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
What version of Windows, the command should require a UAC prompt on any version of Windows greater than 8.
– Ramhound
Jul 15 '16 at 11:38
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
The local and target machines are both running Windows 10. When running psexec on the local machine, from a non-elevated prompt, script.bat runs on the target machine elevated. However, this doesn't happen if the local and target machine are the same. The user is a domain account in the Administrators group on both machines.
– Franzl
Jul 15 '16 at 11:57
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
You are right. My guess is it needs to access \localhostadmin$ and that's an administrative share. so, because it's a local address, it tries to use the current token, instead the credentials you provided.
– NetwOrchestration
Jul 15 '16 at 12:38
@Ramhound I just tried on a system with disabled UAC and
LocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.– NetwOrchestration
Jul 15 '16 at 12:45
@Ramhound I just tried on a system with disabled UAC and
LocalAccountTokenFilterPolicy
set to disabled (accesible administrative share from network) and still no luck! It's something sysinternals should fix.– NetwOrchestration
Jul 15 '16 at 12:45
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1101168%2fwindows-10-psexec-localhost%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This is due to the differences between Windows 10 and Windows 7, Windows 10 elevates a process by implicit request from a user, Windows 7 didn't require that
– Ramhound
Jul 15 '16 at 11:37