WMI is agreat way to extend PowerShell’s possibilities and create new functions that will collect data, or create things in our favorite tools.

It is possible to write functions in powershell that will create objects based on the .put() functionality.

In my case I have been pretty much using PowerShell to write funcitons for SCCM 2007 / 2012. I bumped in a problem while coding a function for SCCM 2007, and more precisly the “Software update deployments”.

As you probably know,  trying to script functions that use the .Put() methods, it can be sometimes a hell of a problem when it doesn’t work immediatly and you need to troubleshoot it.

Espcially when you have a BUNCH of parameters to pass. And need to identify which one is making your day difficult, because the errors that WMI return us are generic errors, and there is not much to digg-in in order to troubleshoot.

Wmi .Put() error

WMI .Put() error.

In the above screenshot, i have passed around 20 parameters to my function. All are present, and based on the result of an SQL query.

The properties of the SQL queries return, can differ from the WMI inputs. Especially on their formats.

This means that for exmple for a specefic value SQL returns one type, and WMI asks for another one.

A good example is the StartTime of the Software update assignment. In SQL, it is returned as a string respectnig the following format : 06.12.2013 16:24:00 And of course, WMI wants a String (as well youpi !) BUT respecting this (very logic) format : 20130612162400.000000+120 (Yeah, why should our daily work be easy anyways ??)

So i wrote a function that converts a

[dateTime] format directly into that WMI time format. (You can find it here).

So lets cast it !



Ok. That was easy.

Ho but wait.  I haven’t set a start date THAT long ago in the past.


Software update deployment example

I actually made it available on the 06 of december 2013. Not the 12 of july 2013 as you can see on the screenshot below.

An importing thing to note here, is that the time format returned by the SQL query is in US time format.

Which means that if you work in Europe, well, you will have to convert that as well !

Actually, the solution here is pretty simple (once you know it of course !) but since casting doesn’t work, what other possibilites do we have ? Get-date ? Ok. Le’s give it a try !


Parsing sql time

So thats more like it ! Now we can use this value returned value with my Convert-ToWMITime function.

So, this was for the easy part. Because you can easily find informatino on the interent on what time format the WMI SMS_SoftwareUpdateAssignment class needs for the startime property.

But now we have all our properties, but the Put() methods still throws us generic error messages.

We got used in powershell to have a more specefic message. At least it would mention the parameter that is incorrect. But here, we have nada, niete, rien, nothing !

Even in the $error default variable there is not more informatino available. So how do we find detailed information on this WMI error ?

On the WMI error itself, i still dont know actually (Please let us know if YOU know how to have more information about an WMI error used in PowerShell).


Since i am scripting things related to SCCM, there is actually one log file that is going to help us A LOT : The SMSprov.log


On Windows-noob.com it says that Smsprov.log – Records WMI provider access to the site database

Which is exactly what we are looking for !

[important]The SMSProv.log file is generaly located here : “C:\Program Files (x86)\Microsoft Configuration Manager\Logs\smsprov.log“[/important]


(Detailed information about configMgr log files can be found here : http://www.windows-noob.com/forums/index.php?/topic/1105-sccm-logs/)

So lets look into this error file :


SmsProv.log error

And tadaa ! We have finally INFO !!

We now can see that the  problem seems to come from the ‘ UseGMTTimes’ property. It is NULL, but ican’t be NULL.

After a quick verification, i could see the following:


Logic, since the SQL query only returns strings. (Is it logic ??).

Anyways, i resolved this by casting the SQL return directly to a bolean value.

(Casting any number, negative or positive value except for 0, to a [bool] will convert the value to $true.

Casting 0 to [bool] will return $false)

So i fixed the first issue like this :

By relaunching the console i had another error.


WMI .Put() error 2

(Actually it was the same as you can see on the image above).

I checked the SMSProv again, and found this this time:


SmsProv.log error 2

After checking my function, i noticed i had a typo in my variable “$LogComplianceToWinEvent”.

I correct it. And tadaaa ! It worked !!


So, if there is one thing you need to remeber :

  1. SMSProv.log (If you are scripting with SCCM)
  2. Types ! (Especially if you are working with results that are extracted from SQL queries and not from WMI).
  3. Culture. As in the example of the starttime, it might work during your tests, but the dates could be wrong. Rember that if you work in europe, the SQL times returned are probably not fitting the european datetime format.

But that is 3 things ! ? Yes yes, i know. Doesn’t matter. Let’s say it is one thing that is composed of three elements 🙂

By | 2016-10-19T21:00:18+00:00 January 12th, 2014|ConfigMgr 2007, Header, PowerShell, Sticky|4 Comments

About the Author:

Stéphane is a dynamic and passionate Cloud and datacenter Microsoft MVP since. He is the founder of the Basel PowerShell user Group (BPUG), the co-founder of the French Speaking PowerShell UserGroup (FRPSUG), author, blogger, and received the community award "PowerShell Hero" from PowerShell.org. Stéphane has implemented microsoft infrastructure solutions in various countries of Europe and is currently working in Basel / Switzerland. Stéphane help his clients to reduce their global infrastructure costs by implementing Microsft infrastructure solutions by combining great products such as System Center, Windows Server, with heavy automation using Windows PowerShell. Stéphane loves languages, Belgium beer, French cheese and French Wine. If any of these topics are of your interest, don't hesitate to come and say hi.


  1. […] How to troubleshoot WMI errors while scripting with PowerShell […]

  2. DexterPOSH January 17, 2014 at 3:55 pm - Reply

    Yeah…that makes more sense now 🙂
    Thanks for explaining that.

  3. Stephane January 17, 2014 at 11:47 am - Reply

    Hello Dexter,

    Thanks for your comment. Indeed, that would work also, and it actually might be a bit more ‘readable’.

    But this was originally designed to receive input data from an SQL query. (I took it out of the context in order to demonstrate the SMSprov.log).
    The SQL query returns data that is quite often untypted (or at least, PowerShell thinks it is a string if you don’t do anything about it^^).

    So the ‘0’ actually referes to a variable that contains the value “UseGMTTime” returned from the SQL query. The SQL query returns either “0” for false, or “1” for true. Casting it avoided me to do a If (0){$UseGmtTime=$false} etc.. 😉

  4. DexterPOSH January 17, 2014 at 11:21 am - Reply

    Hi Stephane Sir,

    I think instead of doing this:
    $UseGMTime = [bool]0

    $NewSoftwareUpdateAssignment.UseGMTTime = $UseGMTime

    you can do this:
    $UseGMTime = $false
    $NewSoftwareUpdateAssignment.UseGMTTime = $UseGMTime

    because the $false is essentially a boolean type value
    C:\> $false.GetType().fullname

Leave a Reply

%d bloggers like this: