Re: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-04 Thread Paul Williams
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: ActiveDir@mail.activedir.org
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

blocked::http://www.LissWare.Net cid:609343613@02122006-153C

mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

Home Page: http://www.LissWare.Net blocked::http://www.LissWare.Net
Where am I? http://map.LissWare.Net blocked::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

RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-03 Thread Guy Teverovsky

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

RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-02 Thread Alain Lissoir
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

 blocked::http://www.LissWare.Net cid:114265316@01122006-02BE

  _  

 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

Home Page: http://www.LissWare.Net blocked::http://www.LissWare.Net 
Where am I? http://map.LissWare.Net blocked::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

RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-02 Thread joe
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

 blocked::http://www.LissWare.Net cid:114265316@01122006-02BE

  _  

 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

Home Page: http://www.LissWare.Net blocked::http://www.LissWare.Net 
Where am I? http://map.LissWare.Net blocked::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

RE: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-02 Thread Alain Lissoir
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

 blocked::http://www.LissWare.Net cid:609343613@02122006-153C

 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

Home Page: http://www.LissWare.Net blocked::http://www.LissWare.Net  
Where am I? http://map.LissWare.Net blocked::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 support better. No commitments here

Re: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC

2006-12-01 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

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

2006-12-01 Thread Thorbjörn Sjövold
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

2006-12-01 Thread Guy Teverovsky

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

2006-12-01 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
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/