I have a script that pulls WmI volume info. I have this in a try/catch. When the wmi fails, which it should for one server, the catch does not catch it. No error is generated with the Catch. NOTHING.
All other 110 exeuctions work perfectly.
I also added -ErrorAction Stop and it does not pickup a failure either.
There is nothing wrong with the try/catch, it picks up other errors just fine.
$results = @(Get-WmiObject -Query $mySelect -ComputerName $myServerIP | Select-Object Capacity, Caption, FreeSpace, Label, Name, SystemName, SystemVolume)
First of all - instead of Get-WmiObject you should use Get-Ciminstance.
To make a try block catch an error it needs to be a terminating error. If the cmdlet you’re using does not cause a terminating error by default you have to force it with the parameter
You may read more about:
Thanks Olaf. Then that explains it.
I am doing a proof-of-concept for moving my SSIS code, which I wrote years ago, over to powershell. The SSIS object detects the connection erorr and is a terminating error. The powershell object appearently does not. I will come up with another work around.
Either I’ve got something wrong or you. Most of the times it’s enough to add the paramter like this:
$results = @(
Get-WmiObject -Query $mySelect -ComputerName $myServerIP -ErrorAction Stop |
Select-Object Capacity, Caption, FreeSpace, Label, Name, SystemName, SystemVolume
Nope. You have nothing wrong. I had put in -ErrorAction STOP at the same spot as you and it would not trigger an error. So, it proves what you thought - it is not an error.
What I am going to do is to just count the entries in the return array. If 0 then I force an internal error with throw to flow into my catch.
I just noticed that I told you the right thing in the first place but I put the wrong to the code in my second anser. … SilentlyContinue instead of Stop … corrected it now.
I understand. For right now, I will use WMI for a bit longer. But, STOP still does not pull an error.
I have another workaround which I will use.