It's great to see folks using PowerShell's Remoting features to run commands on remote machines. It's definitely the way of the future, but it can be a bit tricky.
Local resources only
To start, make sure your command isn't trying to access resources that aren't contained locally on whatever machine you've Remoted to. For example, suppose you're on Computer A running Windows 7 or Windows 8. You use Remoting to transmit a command to Computer B, which is running Windows Server 2008 or later. The command must be able to operate entirely from resources contained on Computer B. It's not allowed to access the network in particular.
Why? It can't do this because Remoting delegates your credential to Computer B, but Computer B isn't permitted to delegate that credential any further for security reasons.
If you absolutely need this to happen, you can enable multi-hop delegation by enabling a protocol called CredSSP. There are a number of security concerns with this, so you need to make sure you understand these concerns before proceeding. You can find more information in the free e-book, Secrets of PowerShell Remoting, which has an entire section devoted to CredSSP.
It's all in the timing
Another possible problem with the command could be timing. When you run a command locally by manually typing the command and hitting "Enter," it takes time to type, hit "Enter" and read the results. By the time you start typing the next command, you know everything from the first command is complete.
This isn't necessarily the case when you send a batch of commands to a remote machine. It might execute the first command then proceed to the second command before the first one is done. This is especially possible with external commands that launch separate processes or threads.
To troubleshoot this, use Enter-PSSession to connect to the remote machine and manually run whatever command(s) you've been trying to send over. If they work, they will either work in a batch using Invoke-Command instead, or you have a timing issue.
You can resolve timing issues a few ways. You can throw in some Start-Sleep commands to make the shell pause while a command completes. You can also check for pre-requisites, such as the existence of a file, before proceeding with another command, having the shell sleep for a moment and re-checking before you continue.
External command woes
Another possibility, and this only applies to external commands and not native PowerShell cmdlets, is that the remote machine is misinterpreting your command. In PowerShell v3, preceding external commands with two dashes ("--") tells the shell to not even try to parse the command, but to pass it to Cmd.exe as is. This often resolves issues with external command syntax.
The remoting rules
If you're able to successfully run a command by logging directly into the console of the remote machine through a Remote Desktop connection or by physically walking up to the server, but the command won't run via PowerShell Remoting, then you may have hit upon an "environmental snag."
When you Remote into a machine using Invoke-Command, Enter-PSSession or some other mechanism, you don't get a full interactive desktop session like you do when you log onto the console or a Remote Desktop session. PowerShell doesn't execute profile scripts and may not have a full user environment to work with. I haven't seen a lot of commands that failed for that reason, but there are probably a few out there.
If this is your problem, then you can try to resolve it by scheduling your command on the remote machine since Windows' Task Scheduler gets a full user account to work with. This is not guaranteed to fix the problem, but it's worth a shot.
If that doesn't work, then you might just be stuck. If your command needs a full, interactive desktop environment in order to run, then you'll just have to run it that way.
ABOUT THE AUTHOR
Don Jones is one of the world's most well-known and respected PowerShell experts and educators. He's the co-author of three books on PowerShell, and you can find him online, including his PowerShell Q&A forums, by visiting DonJones.com.
This was first published in September 2012