Inspired by my previous question here, I've been experimenting with PSExec.
The goal is to trip off some fairly simple scripts / programs on one WindowsXP machine from another, and as PowerShell 2 doesn't yet do remoting on XP, PSexec seems like it'll solve my problems nicely.
However, I can't get anything but the "Access is Denied" error.
Here's what I've tried so far:
I've got a pair of WindowsXP MCE machines, networked together in a workgroup without a server or domain controller.
I've turned off "simple file sharing" on both machines.
Under the security policy, Network Access: Sharing and Security model for local accounts is set to Classic, not Guest for both machines.
There is an Administrative user for each computer that I know the passwords to. :)
With all that, a command like "> psexec \\otherComputer -u adminUser cmd
" prompts for the password (like it should) and then exits with:
Couldn't access otherComputer:
Access is denied.
So, at this point I turn to the community. What step am I missing here?
Add the following registry DWORD to the remote computer and it should fix the issue.
Problem Solved.
It turns out that, by default, Windows won't let you remote in with a user account with an empty password. For the purpose of experimenting with PSExec I had changed the password of the admin account on the target machine to nothing, thinking that would reduce the amount of typing needed. Turns out, that was my problem, and once I put a password back, it all worked perfectly.
However, this set off another investigation - If anyone wants to use PSExec with an empty password, here's what you need to do (under Windows XP MCE, anyway):
I think PSEXEC relies on being able to open the ADMIN$ share, so check that with the same credentials,
If you type
into my computer and authenticated as adminUser does it work?
I assume you did use a double slash and the system stripped it.
You do need the standard windows file sharing turned on and allowed through the firewall for this to work.
I encountered this error when running PSExec from a non-elevated command prompt (on Windows 7). Running the command from an elevated command prompt fixed it.
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.
Is Windows Defender or other malware protection running? Is it blocking? I know Windows Defender is capable of doing so.
Capturing traffic using Wireshark can often help track down the issue in these situations. You can look at the SMB traffic and see how Windows is trying to authenticate or if it even gets that far in the first place in the case of firewalls blocking traffic etc.
Another thing to check is whether your antivirus is blocking psexecsvc.exe. I just ran into that with Sophos. I was getting an Access Denied and saw that Sophos was blocking PSEXEC from the Application log.
Here's an idea that worked for me. Rather than passing the username and password to psexec with the -u and -p parameters, instead first open a command prompt running in the context of that user:
When prompted, enter the password. Then from that new command prompt, run psexec as normal: