Windows Inventory discovery problem

May 7, 2013 at 10:52 AM

I seem to be having an issue when using the Windows Inventory where the "Test WMI connectivity" gets stick on the very last node, in my case 207 of 208.

I've attempted to run it a number of times and it keeps happening.
Please help.

May 7, 2013 at 1:37 PM
Hi Derek,
Thanks for checking out SQL Power Doc. I've run into the problem you're describing once before and it turned out to be that a machine I was trying to make WMI calls against was pegged at 100% CPU (and for the most part unresponsive) but responsive enough that the WMI call would never error out.

The challenge is figuring out which one of the 208 machines is the problem. If you set -LoggingPreference Verbose when you run the script the log file would contain all the details and with a bit of parsing you could figure out which machine hasn't returned a result yet. Admittedly that's kludge so option 2 might work better for you - open Resource Monitor on the machine where the script is running and look at the TCP Connections in the Network tab. You may have to filter by the PowerShell process ID but that one connection should eventually be the only one hanging around and at the point you'll know which remote machine is holding things up.

I've got an idea for how I may be able to set a timeout external to the WMI call that I'm going to look into. If it works like I think it will I can put it into the next planned release so that nonresponsive machines don't hold things up.

May 7, 2013 at 3:35 PM
Thanks Kendal,

I'll definitely give the verbose logging a try and see what I can find. It would be great if the WMI call can make use of a timeout feature, perhaps even be included with a switch like " -timeout 30" or something to accommodate for running over slow WAN links? Just my suggestion.

Thanks again.
May 7, 2013 at 7:01 PM
Try out the beta that I pushed to the downloads section. I added a 30 second timeout when checking for WMI connectivity. If the timeout is exceeded you should see a message in the log file that tells you which machine the timeout occurred on.

May 8, 2013 at 10:01 AM
Hi Kendal,

I've tested out the beta and the same thing is happening. I was able to check on resource monitor to find the computer in question which was based at a remote site. Oddly it still seems to hang on the WMI call and does not timeout.

I am sure this is an issue with the PC and I'll be troubleshooting it later today. Another question on that, I see there is a parameter for -ExcludeComputerName, will this work for IP addresses or could you consider that for a future release.

May 8, 2013 at 10:37 AM
Hi Derek,
Hmm, I'll have to take another look at the code and see if I missed something on the timeout. Was there anything in the log file about a WMI timeout exceeded?

You can exclude by IP address by using the -ExcludeSubnet parameter to specify a subnet range with a /32 subnet for a specific host. For example, to exclude the loopback IP it would look like -ExcludeSubnet