GetObject("winmgmts:\\.\root\cimv2") Syntax Error

[NFI]

Hello,

I run a script during the unattended install of my XP clients which moves them out of the default Computers OU in AD, into another OU. To attach to the WMI (and ultimately get the computer name), I use the following line;

Set oWMI = GetObject("winmgmts:\\.\root\cimv2")

This has worked fine for months, but yesterday, I decided to slipstream SP3 into my build folder using nLite and now this line throws the following error;


Error: Invalid Syntax
Code: 800401E4


I'm assuming some object has changed between SP2 and SP3 which means I can't connect to the WMI in this way, but does anybody know what I can do to get around it?

Many thanks,

Paul

 

[Golom]

I found the following here and it seems to work with SP3 installed.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" _
    & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
    ("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
    Wscript.Echo "Windows Folder: " & _
        objOperatingSystem.WindowsDirectory
Next

 

[NFI]

Hiya,

thanks for your help. This script quits at the same line (set objWMIService = ...) with the same LDAP Invalid Syntax error...

Have you slipstreamed SP3 into your build or have you installed it over SP2?

Thanks,

Paul

 

[NFI]

OK, having played about with this all morning, I'm pretty sure the problem is in the way the WMI components are either installed or registered with SP3.

I re-registered all of the WMI DLLs and EXEs like this;

cd /d %windir%\system32\wbem 
for %i in (*.dll) do RegSvr32 -s %i 
for %i in (*.exe) do %i /RegServer

...which produces a few errors during the registering process (but I don't think they matter) but which apparently gets my...

Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

...line working.

However, now the next line...

Set cItems = oWMI.ExecQuery("SELECT * FROM Win32_OperatingSystem",,48)

...falls over with the following error;


Error : Library not registered
Code : 8002801D


...so I guess the re-registering process has broken something...

According to Microsoft, the library that contains execQuery is wbemdisp.dll, but regsvr32 tells me this has registered fine.

So...any ideas anybody?

Thanks,

Paul

 

[tsuji]

You should run wmimgmt.msc to inspect upon the security settings for the account. It might be changed. Step-by-step see:

http://community.spiceworks.com/education/projects/Setting_The_Default_WMI_Namespace_Security

Syntax error may just be a misleading message.

 

[NFI]

Thanks for that - I couldn't get wmimgmt.msc to run, as my system reckoned it wasn't installed. So, I ran some wmi diagnostic package from microsoft on it and it came back full of errors and missing components. It looks like my nLite slipstream has made a right old hash of WMI. As an interim fix, I'm installing all the WMI components from the build folder after the unattended install like this...

rundll32.exe setupapi,InstallHinfSection WBEM 128 %windir%\inf\wbemoc.inf

...and that seems to fix my problem. It's a bit of a mess, though I thought slipstreaming with nLite would be a nice easy way of doing this, but I think I'll go back to using /integrate...

Paul

 

[BigR77]

Hello..

I encountered all activities that uses WMI is not working. I'm suspecting the problem got to do WMI.

Digging into this,

When I connect to the WMI in Computer Management panel, It gives the following message in General tab
Failed to connect to <local computer> because "Win32: Access is denied"
And Even 43 and Event 60 was generated in Event Application log.

WMI ADAP failed to connect to namespace \\.\root\cimv2 with the following error: 0x80070005

WMI ADAP was unable to process the performance libraries: 0x80041001

In addition, I have run WMDIAG tool and encountered that this is a permission issue, caused by DCOM security modifications. I tried to restored back at local policy but cannot. Any idea? Plz advice.

 

[dm4ever]

I've had a fresh WinXP SP3 install and WMI should still function the same way. It really appears that WMI is corrupted on that machine for whatever reason.

You probably ran this already to register the WMI files but here it is.... if this doesn't work... you may consider copying the WMI files from a working machine and re-running it

net stop winmgmt
cd /d %windir%\system32\wbem
for %i in (*.dll) do RegSvr32 -s %i
for %i in (*.exe) do %i /RegServer
for %i in (*.mof, *.mfl) do Mofcomp %i
net start winmgmt

You can download an application called unlocker (releases any file locks) if you have problems replacing any of the files

--------------------------------------------------------------------------------
dm4ever
My philosophy: K.I.S.S - Keep It Simple Stupid

 

[NFI]

Hiya,

Thanks for that - I found those instructions somewhere and tried them, but the WMI system was so badly corrupted, it still didn't work afterwards...

I discovered the problem was to do with the way I was installing XP SP3 - I was using nLite to do it and it appeared it was just making a hash of the entire WMI system...

I slipstreamed SP3 into the install package myself and installed it using unattend scripts instead and it's worked fine ever since.

It's a bit of a shame, as I like the way nLite installs XP - my way looks a bit ad-hoc, but at least it works...

Cheers,

Paul

 

[dm4ever]

That's weird since I used nLite to create one of my CD's (winxp sp3) and it worked just fine.

--------------------------------------------------------------------------------
dm4ever
My philosophy: K.I.S.S - Keep It Simple Stupid