I am not familiar with protect or this issue, but it may be beneficial to rule out the protect application by running a similar WMI query against your target windows guests manually. Keep in mind that WMI will not communicate with linux (of course) and may need extra patching on older Windows operating systems to work.
I've run a similar scenario with a personal Powershell script to query the last reboot (separate from Protect) and came close to the same issue. So, I'm beginning to think this might be a remote server issue or a WAN issue; more than likely a remote server issue. I can get onto the remote server and run the same WMI query back to a remote server here at HQ and have no issues. So, again, this might be a specific issue on this remote server.
Can you perform a full asset scan on that same system successfully with Protect? If it errors out it may give you more idea why it can't connect with WMI. Also if the asset scan fails to perform a hardware asset scan it might help to refer to this article: http://kb.vmware.com/kb/2008267
No, not able to get a full scan, even though it states it is successful, I see that it errors at WMI during the scan steps.
'Cannot connect to WMI service. It might be stopped or firewalled.'
I've completed a 'enable-psremoting' and even made sure Windows firewall is completely turned off and the WMI service is running. I guess I am going to have to do more WMI troubleshooting.
Here's another tool you can play with while working your firewall/permissions issue afflicting your WMI:
PS - On an unrelated note, please keep in mind that PSRemoting and WMI can be mutually exclusive (i.e. generally speaking, there is no need to enable psremoting in order to use WMI against a target server. Of course, once you do you can get tricky with it. But not required.
As grasshopper pointed out the psremoting is not required for this. The asset scan completed with errors. The asset scan has two parts. The software scan is not WMI based, but the hardware is. Adam was having you do that to confirm it was definitely WMI that was causing the issue. You can try the telnet test from the KB Adam sent to confirm that 135 is available. If that is open and WMI service is started then we will likely have to know more about your situation. OS of the target? Is it domain joined? Can you perform this script against any machines in your environment (or an asset hardware scan)?
Asset scans require port 135, while patch normal scans do not.
- Verify if Port 135 is listening on the Target Machine.
- Verify if you are able to successfully Telnet to port 135. For example, Telnet MachineName 135. You can use the IP address instead of the machine name for this test.
- Check if you receive a Connection Refused error or see a blank screen with a flashing cursor. The blank screen with a flashing cursor indicates success.
- If firewalls are enabled, - port 135 and other required scanning ports must have an exception.
Thanks, Gents, for the input.
After further troubleshooting and testing with domain policies in our environment, it seems there were some firewall settings in our Default Domain Policy that were blocking any type of WMI query. After making some changes (basically just turned Windows firewall off completely for all Profiles in Windows 2008), I was able to complete a full asset scan and launch a script on my test server.
Windows firewall will get you every time.