[ActiveDir] 100% CPU utilization when querying Win32_Account on DC
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
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/
RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
Sorry, AFAIK there is no workaround, and even worse, I remember seeing this
class contacting every trusted domain and enumerating the accounts there too,
so this WMI class is one to normally stay away from, so "Not Optimized" is the
understatement of the year :)
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical reporting,
http://www.specopssoft.com/products/specopsgpupdate/default.asp
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Friday, December 01, 2006 3:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
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
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/
Re: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
I'd direct you to Rod and the gang at Myitforum as they are where the
SMS gang hangs out and have the plug into the folks that can give you
more info (IMHO)
Guy Teverovsky wrote:
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/
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will
hunt you down...
http://blogs.technet.com/sbs
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/
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> 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 http://www.LissWare.Net> cid:114265316@01122006-02BE _ <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] Home Page: http://www.LissWare.Net http://www.LissWare.Net> Where am I? http://map.LissWare.Net 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
RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
Good post but yuck. Amazing how many issues you avoid by avoiding ADSI, WMI, CDOEXM, and the other MSFT frameworks designed to make life "easier"... -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir Sent: Saturday, December 02, 2006 12: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> 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 http://www.LissWare.Net> cid:114265316@01122006-02BE _ <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] Home Page: http://www.LissWare.Net http://www.LissWare.Net> Where am I? http://map.LissWare.Net 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
RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
You must take into account that not everyone is a Win32 API or LDAP API C or C++ developer to write its own logic and create its own tool to perform the management task their business requires. Abstraction layers like WMI, ADSI, CDO, XMLDOM, WSH, ADO and so on ... are helping thousands of people to write scripts and applications without having to dig into the API programming level. Both worlds have pros and cons. The API programming level requires a more specific programming knowledge, the abstraction layers introduce a proxy, simplifies the access pattern and obviously have a performance cost. I think that none of the two worlds have to be rejected, they just need to be used correctly and when appropriate. This why Microsoft is documenting Win32 API, COM interfaces and .NET API. If the COM abstraction layers were that yuck, programming environments like WSH and/or VB6 would have not been so heavily used and successful. Are abstraction layers perfect? Clearly not. Are they useful? Yes for sure. Is there room for improvement? Always. Regards, /Alain Alain LISSOIR http://www.LissWare.Net> cid:609343613@02122006-153C <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] Home Page: http://www.LissWare.Net http://www.LissWare.Net> Where am I? http://map.LissWare.Net http://map.LissWare.Net> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, December 02, 2006 1:33 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC Good post but yuck. Amazing how many issues you avoid by avoiding ADSI, WMI, CDOEXM, and the other MSFT frameworks designed to make life "easier"... -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir Sent: Saturday, December 02, 2006 12: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> 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 supp
RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
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 mad
Re: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC
MONAD for Exchange is supposed to fix that but I am expecting tremendous scaling issues in the environments I play in with it and quite frankly have even admitted that I would rather see WMI as it doesn't saturate the network lines passing data that isn't being requested. I agree with you here. I've started playing with PowerShell, and was trying to prove that you could use the WinNT provider to someone. It took me ~5 minutes to get as far as C* when outputting all user objects in my domain. And we're only talking ~40,000 in this particular instance. --Paul - Original Message - From: "joe" <[EMAIL PROTECTED]> To: Sent: Sunday, December 03, 2006 5:01 PM Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC Oh I see that. On the flip side, companies that produce professional products like x, y, and z[1] etc should have the skill sets to produce more efficient and directed applications that don't have a reliance on those abstraction layers and use the more efficient APIs in ways that are directly relevant to the goals of the applications and that they have a greater understanding of. Obviously someone may not have a super strong understanding of the core APIs but at least there is only a single level where problems can be introduced versus the multiple levels that can be introduced in the abstractions such that you have to try and figure out at what level the issue is at. Possibly if the abstraction layers had amazing logging that could be enabled to track issues and explain what they are translating the requests to at the lower levels it might be easier for someone to identify where the issue cropped up. One issue I see is someone who can write a basic vbscript based on these frameworks think they are a programmer and start producing tools that they sell. They have no understanding of the underpinnings of the overall system and quite frankly, to scale things up, they really ought to, the abstractions are not great in that arena and to be fair, I don't believe they really were designed to be. It was more to get the masses so they could do basic things. Another issue I see is when someone only published say a WMI interface into something. I have that issue with Exchange 2000/2003 as they really did a poor job with a lot of that from being poor performers to not performing correctly at all. I took this up with the Exchange PSS Support folks and finally got the great answer of WMI isn't designed to be used for monitoring... How do you argue that point? Unfortunately the only other recourse is to try and work through completely undocumented MAPI stuff and MAPI is already painful and sucky at best though it was designed to be a nice abstraction layer to make lives easier. MONAD for Exchange is supposed to fix that but I am expecting tremendous scaling issues in the environments I play in with it and quite frankly have even admitted that I would rather see WMI as it doesn't saturate the network lines passing data that isn't being requested. [1] Names withheld to protect the guilty. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir Sent: Saturday, December 02, 2006 6:38 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC You must take into account that not everyone is a Win32 API or LDAP API C or C++ developer to write its own logic and create its own tool to perform the management task their business requires. Abstraction layers like WMI, ADSI, CDO, XMLDOM, WSH, ADO and so on ... are helping thousands of people to write scripts and applications without having to dig into the API programming level. Both worlds have pros and cons. The API programming level requires a more specific programming knowledge, the abstraction layers introduce a proxy, simplifies the access pattern and obviously have a performance cost. I think that none of the two worlds have to be rejected, they just need to be used correctly and when appropriate. This why Microsoft is documenting Win32 API, COM interfaces and .NET API. If the COM abstraction layers were that yuck, programming environments like WSH and/or VB6 would have not been so heavily used and successful. Are abstraction layers perfect? Clearly not. Are they useful? Yes for sure. Is there room for improvement? Always. Regards, /Alain Alain LISSOIR http://www.LissWare.Net> cid:609343613@02122006-153C <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] Home Page: http://www.LissWare.Net http://www.LissWare.Net> Where am I? http://map.LissWare.Net http://map.LissWare.Net> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, December 02, 2006 1:33 PM To: ActiveDir@mail.activedir.org Subject: RE:
