You're sitting at your desk, trying to push a remote command to a client's workstation—maybe you're running psexec \\workstation -s cmd or firing off a sc \\workstation start some_service. And instead of the expected output, you get: "A failure occurred when executing a remote administration command. The exact error code is: 0X0000090B." That's the NERR_ExecFailure message, and it's a classic in small business networks. I've hit this more times than I'd like to admit, usually right when the client is breathing down my neck.
What's actually going on
Under the hood, this error means the remote machine couldn't execute your command. It's not a network timeout or a DNS issue—the connection was made, but something on the target side stopped the actual execution. Think of it like this: you dialed the phone, someone picked up, but then slammed the phone down before you could talk.
Three things cause this 90% of the time:
- Permissions are too tight – The account you're using doesn't have the right to run that command remotely, even if it looks like an admin.
- The Remote Registry service is disabled – This service is the workhorse for many remote admin commands. If it's off, you get this exact error.
- Firewall or SMB blocking – Windows Firewall or a third-party AV is silently blocking the RPC call, even though basic ping works.
I once spent an hour chasing this on a client's server, only to find their antivirus had "protected" the registry service by disabling it. The fix took 30 seconds once I knew.
The fix that works most of the time
Here's the step-by-step I run through. Do them in this order—don't skip ahead, because each step rules out the previous cause.
Step 1: Check the Remote Registry service on the target
On the machine that's giving you the error, open an admin Command Prompt or PowerShell and run:
sc query RemoteRegistryIf the STATE shows STOPPED, start it and set it to automatic:
sc config RemoteRegistry start= auto
sc start RemoteRegistryIf it's already running, go to Step 2.
Step 2: Verify your account has the right permissions
You need to be a member of the Administrators group on the target machine. Not "Domain Admins" by default—actually a local admin. To check, run this from an elevated prompt on the target:
net localgroup administratorsIf your account isn't listed, add it (assuming you have another admin account):
net localgroup administrators yourdomain\yourusername /addAlso, if you're using psexec, make sure you're not using the -u flag with a domain account that's been locked out. I've seen that cause this exact error.
Step 3: Check the Windows Firewall rules
Remote admin commands need the Remote Service Management and Remote Event Log Management inbound rules enabled. On the target, run:
netsh advfirewall firewall set rule group="Remote Service Management" new enable=Yes
netsh advfirewall firewall set rule group="Remote Event Log Management" new enable=YesIf you're on a domain with Group Policy overriding firewall settings, check that the GPO isn't blocking these. That's a rabbit hole, but a quick gpresult /h gpo.html on the target will show you.
Step 4: Test with a simpler command
Run a basic remote query to see if it's the command or the system:
sc \\targetmachine query SpoolerIf that works but your original command fails, the issue is with the command itself—maybe a missing file or wrong path. If even this fails, you're still stuck on permissions or SMB.
What to check if it still fails
By now you've covered the big three. If the error persists, look at these next:
- SMB v1 is disabled – Some older remote admin tools rely on SMB v1. Check if it's enabled:
Get-SmbServerConfiguration | Select EnableSMB1Protocol. If it's off and you're using legacy tools, that's your culprit. Don't re-enable unless you must—it's a security risk, but sometimes the business has old software that needs it. - Third-party antivirus – I've seen Symantec and McAfee block RPC calls out of the box. Temporarily disable the AV on the target (just for a test) and retry. If it works, configure an exclusion for the RPC ports (135, 445, and dynamic RPC range).
- Credential delegation – If you're using a scheduled task or a service account to run the remote command, make sure it's allowed to delegate credentials. Check the account in Active Directory under the Delegation tab.
- Event Viewer – Look at the System log on the target for the timestamp of the error. You'll often see a Security event (4625) or a Service Control Manager event (7000) that points to the exact service that failed.
One last thing: if you're trying to run a command that writes to the registry remotely, make sure the target's registry is writable via the network—that's the Remote Registry service again. I've seen admins disable that service for security and then forget they did.
This error is a pain, but it's almost always something simple. Get the service running, the permissions right, and the firewall open, and you'll be back in business. That client of mine? Turned out their IT guy before me had disabled Remote Registry to "harden" the server. Two minutes after I started it, the remote install went through like a dream.