[python-win32] Invalid method parameters with UnjoinDomainOrWorkgroup
mail at timgolden.me.uk
Wed Dec 23 10:03:44 CET 2009
> I am trying to unjoin a machine from the domain and attempted with the
> following code
> import wmi
> wm = wmi.WMI()
> wm.Win32_ComputerSystem.UnjoinDomainOrWorkgroup(2, 'ADMINPASSWORD',
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "C:\Python24\Lib\site-packages\wmi.py", line 396, in __call__
> handle_com_error (error_info)
> File "C:\Python24\Lib\site-packages\wmi.py", line 189, in handle_com_error
> raise x_wmi, "\n".join (exception_string)
> wmi.x_wmi: -0x7ffdfff7 - Exception occurred.
> Error in: SWbemObjectEx
> -0x7ffbefd1 - Invalid method Parameter(s)
> I dont understand why its calling these Invalid method parameters. All that
> it wants is an (Int, Str, Str) when using thru Python otherwise it is (Str,
> Str, int) as described here.
Just to cut the small Gordian knot, you can pass the parameters
by name rather than by position:
(as long as you're using a reasonably recent version of the
wmi module, >= 1.3.2 IIRC).
Unfortunately, the method definition picks up the parameters in the
order in which WMI returns them. Under the covers it's basically doing this:
in_params = [(i.Name, i.Array) for i in method.InParameters.Properties_]
I've got no idea if there is any guarantee about the order of parameters.
As you say, the MOF / schema suggests a different order. FWIW, you can
see it without having to load the MOF file like this:
(Granted, you have to hunt for the method you're after...)
Glancing at a few other method definitions, it does seem as
though WMI is consistently returning params in the reverse
order of their definition in the MOF. If this turns out to
be the case across the board I can easily reverse them as
they come out of WMI, but this will break anyone's code
which has used the old positions.
I shall have to consider this...
More information about the python-win32