Forum Discussion
Get-Service fails but Invoke-Command {Get-Service} succeeds
- Hello everyone,
I ended up engaging the entire Infrastructure team from my office and we managed to solve the problem by slightly loosening our firewall rules. According to my firewall admin: The firewall rule required ms service controller to be allowed.
This issue is now resolved. Thanks.
Ken
I ended up engaging the entire Infrastructure team from my office and we managed to solve the problem by slightly loosening our firewall rules. According to my firewall admin: The firewall rule required ms service controller to be allowed.
This issue is now resolved. Thanks.
Ken
The two commands use completely different connection protocols:
- Get-Service uses RPC (TCP 135);
- Invoke-Command uses WinRM (TCP 5985).
For my environment, I only allow WinRM as without going into the "why", it's most often faster and - indirectly - more secure. I also tend to configure secure WinRM (TCP 5986 using TLS) and block the default non-TLS endpoint (TCP 5985) using the Windows Advanced Firewall (where possible).
In any event, RPC is still commonly utilised in PowerShell and it meets your brief. Just note - purely for educational purposes - that it's also one of the most historically targeted protocols for exploits.
Cheers,
Lain
- Thanks for the explanation. Would you say that the long term solution is to replace "Get-Service ..." with "Invoke-Command {Get-Service ...}"?
Hi, Ken.
For me, personally, there's enough compelling reasons to say yes - when you're specifically talking about running scripts against remote Windows computers.
But people code to their preferences, and if your vendor/third party that authored the script is only interested in the stereotypical "path of least resistance", it might be hard to win that argument with them.
Invoke-Command is hard/impossible (in my opinion) to beat for remote computer tasks of all complexities.
Cheers,
Lain