I’m stumped. We set up our remoting via GPO. All machines are Win 7, the server is Win 2008 R2. When I was a freshly minted posh scripter, I didn’t know any other way to make stuff work than punching holes in the firewall. Now, I know invoke-command is available. However, I was recently told that because my gwmi commands didn’t work without invoke-command, my remoting must be set up incorrectly. My task then, is to get it set up correctly and minimize the exceptions in our firewall. Currently we have 4 firewall exceptions defined in the GPO that make it possible for me to run all the commands I want (so far). They are:
Remote Event Log Management
Remote Service Management
Windows Firewall Remote Management
Windows Management Instrumentation
It’s my understanding that the only one that is supposed to be needed, is Windows Remote Management, which as I’m looking at it now, isn’t even on the above list. I configured a GPO with only the Windows Remote Managmeent exception, followed the steps in the “Secrets of PowerShell Remoting” to set up listeners and stuff. I can establish a session with the remote computer and run some commands. But the gwmi command continues to fail.
get-wmiobject win32_bios -computername rgc115-a
The error message is “RPC server is unavailable…”
When I wrap it in the invoke-command construct, it works just fine.
Get-WmiObject doesn’t use PowerShell remoting; it’s based on the older DCOM / RPC protocols, which aren’t particularly firewall-friendly. You have two options:
If you're running PowerShell 3.0 on all of your machines, you can use the new CIM cmdlets (such as Get-CimInstance instead of Get-WmiObject), which do use the WinRM port.
If you need Get-WmiObject to work, you need to enable both the "Windows Management Instrumentation (DCOM-In)" and "Windows Management Instrumentation (WMI-In)" inbound rules in Windows Firewall. Based on what you've said, it looks like the DCOM-In rule might still be disabled.
There is another option - you can use the WSMAN cmdlets. They became available in PowerShell 2.0. They use WSMAN (WinRM is Microsoft’s implementation of WSMAN) and can access WMI classes without the DCOM ports being opened.
The syntax on these cmdlets is a bit awkward but they work quite nicely. I covered these cmdlets in detail in chapter 17 of Powershell and WMI (www.manning.com)
LOL… just bought two books on powershell (Powershell in Depth and Learn Powershell Toolmaking). Guess I’ll need to buy another one. It’s kind of funny… usually you can find almost everything you need to know about something on the web. But powershell isn’t like that yet. Usually when I buy books, I find that they were not very needed or very helpful and I get most of my info off the net. In one way, I’m glad my posh book purchases are not a waste of money. Wonder if the web will ever catch up to all that can be done with powershell. LOL. Thanks for the tips you guys.
If you want more depth on WMI then PowerShell and WMI will cover your needs. PowerShell in Practice is older but I still use it very frequently - I put all the bits I can never remember into it on the principle that other people probably can’t remember them either
I’ve never actually used them before.