Thanks for the excellent explanation !
Btw, I have just reproduced the same behavior on a test AD hosting 228 user
accounts with the following script:
---------------------------------------------------------------------------------------------------
On Error Resume Next
Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20
arrComputers = Array(".")
For Each strComputer In arrComputers
WScript.Echo
WScript.Echo "=========================================="
WScript.Echo "Computer: " & strComputer
WScript.Echo "=========================================="
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Account where
LocalAccount=True and SIDType=1", "WQL", _
wbemFlagReturnImmediately +
wbemFlagForwardOnly)
For Each objItem In colItems
WScript.Echo "AccountType: " & objItem.AccountType
WScript.Echo "Caption: " & objItem.Caption
WScript.Echo "Domain: " & objItem.Domain
WScript.Echo "FullName: " & objItem.FullName
WScript.Echo "LocalAccount: " & objItem.LocalAccount
WScript.Echo "SIDType: " & objItem.SIDType
WScript.Echo
Next
Next
---------------------------------------------------------------------------------------------------
The script has been running now for 20 minutes with CPU at 100%. The hardware
is a decent workstation 2.66GHz with 1GB of RAM and is not doing much other
than being a DC in a test lab.
If you ask me, it smells like a potential DoS if the script was to be executed
against all the DCs in the enterprise...
I have opened a case with Premier to make it official - our client does want
that specific extension and insists on a fix (and I totally agree with him -
avoiding the use of the class will not remedy the implications of being slammed
by a query like this).
Thanks,
Guy
________________________________
From: [EMAIL PROTECTED] On Behalf Of Alain Lissoir
Sent: Saturday, December 02, 2006 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
Let me step in here to give you some more background ... J
WMI is a 3-tier architecture (See figure at
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_architecture.asp).
The SMS client runs at the level of the client API (3) and submits the WQL
query to WMI at layer 2 (Core WMI service).
This query is handled by WMI core. WMI Core looks after the class in the WQL
query (i.e. Win32_Account) and locates the provider supporting it.
In this case, the provider is CIMWin32 implemented by CIMWin32.DLL (I skip the
explanation about how WMI does that unless someone is interested). Because that
CIMWin32 provider does not support WQL query parsing and is not handling them
by itself, WMI core takes the initiative to actually converts this query into a
full enumeration request to the provider, meaning that the provider is actually
building ALL instances of Win32_Account with all their characteristics. Once
the collection is built, WMI core receives the result set and is then
post-filtering the enumeration set to match the WHERE clause of the WQL query,
which in turn returns the result set requested by the client (SMS in this
case). This is the way how WMI core works with all WMI providers not supporting
WQL queries natively (I mean supporting query at the level of the provider
itself). Actually, this enumeration technique is implemented to support WQL
queries even for providers not supporting WQL queries in their code by design.
A WMI provider may have many capabilities (i.e. Get, Put, enumerations, events,
etc) and one of them is to support WQL queries (which actually is off-loading
WMI core do to the job I just described).
This explanation does not solve your issue, here, but it gives you the
explanation of the “why” where the actual solution is to implement a WMI
provider that supports natively WQL queries and actually performs the right SAM
or LDAP queries against AD (I mean properly scoped). It would be a sort of WMI
provider converting WQL queries into SAM/LDAP queries to put it short.
This class was created way before AD did exist. The presence of AD increases
dramatically the number of accounts available. Although this class with this
provider was working fine during the NT 4.0 time (yes, this class dates from
that period), it is challenged in large AD infrastructure, Make a test with a
small AD infrastructure where you have only 2000 accounts, and everything will
be fine. I can bet that your AD installation is way bigger …
Now, if you use WMI a lot to query the SAM and AD and if you feel this is an
area where some enhancements can be made, let it me know and I will be pleased
to communicate this data point to the team in charge of WMI and the team in
charge of Active Directory, So, we can let them know that it is an important
scenario to enhance and support better. No commitments here, but I will be
pleased to convey the message.
Hope this helps a bit …
PS:
However, if you feel you have WMI issues, you can always use the WMI Diagnosis
Tool 1.0. You can find pointers to it (+Webcast) at http://www.lissware.net.
Note, we will release the version 2.0 early next year.
Regards,
/Alain
Alain LISSOIR
[cid:114265316@01122006-02BE]
________________________________
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Friday, December 01, 2006 7:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
Thanks Susan, but I think this case is different - we are talking about
different WMI class and in my case the query hangs and never returns results.
The ITMU issue is probably a result of intensive load on the CPU when
performing the query you pointed to, but in my case if I let it run for hours
it still never finishes.
I am far from being well versed in WMI, but I'd suspect that here the problem
is caused by WMI not using paging in the query or very inefficient processing
when using both LocalAccout=True and SidType=1 keys.
Guy
________________________________________
From: [EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks
[MVP]
Sent: Friday, December 01, 2006 5:12 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
http://www.myitforum.com/articles/8/view.asp?id=9048
http://www.myitforum.com/articles/8/view.asp?id=9284
Rod's been tracking that on myitforum and the Patch management listserve
for a while now.
Guy Teverovsky wrote:
>
> Hi all,
>
> Recently I had a case where we experiences high CPU utilization after
> deploying SMS client to DCs.
> By now we have identified that the issue was caused by an extension of
> sms_def.mof file containing the definitions of information that should
> be collected from the agent.
>
> The interesting part is that I was able to reproduce the behavior
> without SMS agent. Just execute the following WMI query on your DC and
> see the CPU spikes to 100% and will stay there till you kill the
> wmiprvse.exe process:
> *select * from Win32_Account where LocalAccount=True and SIDType=1*
>
> Now you do not need to explain to me that this is damn stupid to run
> this type of query on a DC, yet I would expect the DC to be able
> to handle the query, but what I see is that the query never returns -
> it just hangs there choking up the CPU till you kill the WMI process.
>
> Almost the same behavior is observed when executing "wmic useraccount"
> from the command line, but in this case the query does return the
> results after a while (~2-3 minutes on ~2K user account AD).
>
> The only thing related to the issue that I was able to find is the
> following KB: http://support.microsoft.com/kb/268715
> ("WMI Query Support for Win32_Group Is Not Optimized") where the
> following query "SELECT * FROM Win32_Group WHERE Domain="workgroup"
> AND Name="smith"" causes the identical behavior. But folks, we are
> talking W2K3 with SP1 and not W2K pre-SP2.
>
> Any chance anyone has stumbled upon it ? Is aware of hotfix ?
>
> Thanks,
> Guy
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
