There are some product architectures created here at Microsoft that I am marvelled at with their simplicity, ease of use, and power. Unfortunately, I do not find WMI to be one of those architectures. With hope, some day we will have a sane replacement for WMI but in the meantime we still need to deal with it and the fact that we use it for most settings in Office Communications Server.
Perhaps the most annoying thing I find is that I'm never told exactly what I did wrong when I attempt to set a value or write a query. Instead, I get a long HRESULT number that, at first glance, tells me absolutely nothing. In this post, I hope to shine a bit of light on this.
The first thing you should do when confronted with this number is try to look it up under the common WBEM error codes. A list of the error codes with descriptions can be found here. You should be able to find your error code there along with a description that may tell you what happened. Of course, if the error code is WBEM_E_FAILED or is WBEM_E_UNEXPECTED this will not help you very much, except to confirm that there is indeed a problem. You may also be puzzled if one of your parameters cannot be null but you do not know which one.
From here the best solution is to use OCSLogger. You can find OCSLogger in \Program Files\Common Files\Office Communications Server 2007\Tracing. You will need to run it on your front end or home server (depending on the edition). Under "Logging Options" you should choose "LcsWmi". Under level, choose "All" and under Flags choose "All Flags". Leave all other options at their defaults. Then click start logging and rerun the WMI operation.
While most of the data generated is only readable by Microsoft, you will be able to read the errors and get enough information to likely determine what the problem is. If you need to follow up with Microsoft on the issue because the logs are not obvious, you can use the same logs to send to Microsoft.