| Author | Messages | |
activedir3
Posts:0
 | | 12/01/2006 9:48 AM |
| P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
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 tohandle 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 uponit ? Is aware of hotfix ?
Thanks,
Guy | | | |
| sbradcpa
Posts:317
| | 12/01/2006 10:12 AM |
| 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/ | | | |
| AD00000981
Posts:0
| | 12/01/2006 10:27 AM |
| P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
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" istheunderstatement 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Guy
TeverovskySent: Friday, December 01, 2006 3:49 PMTo:
ActiveDir@mail.activedir.orgSubject: [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 tohandle 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 uponit ? Is
aware of hotfix ?
Thanks,
Guy | | | |
| activedir3
Posts:0
| | 12/01/2006 10:36 AM |
| P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| sbradcpa
Posts:317
| | 12/01/2006 11:40 AM |
| 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| listmail
Posts:454
| | 12/02/2006 4:33 AM |
| 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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).
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
_____
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| alainlissoir
Posts:3
| | 12/02/2006 6:37 AM |
| 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
cid:609343613@02122006-153C
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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).
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
_____
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| alainlissoir
Posts:3
| | 12/02/2006 12:37 PM |
| 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
_____
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| activedir3
Posts:0
| | 12/03/2006 10:15 AM |
| @font-face {
font-family: Wingdings;
}
@font-face {
font-family: Cambria Math;
}
@font-face {
font-family: Calibri;
}
@font-face {
font-family: Tahoma;
}
@font-face {
font-family: Verdana;
}
@page Section1 {margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
P.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"
}
LI.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"
}
DIV.MsoAcetate {
FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"
}
SPAN.EmailStyle18 {
COLOR: blue; FONT-FAMILY: "Arial","sans-serif"
}
SPAN.BalloonTextChar {
FONT-FAMILY: "Tahoma","sans-serif"
}
.MsoChpDefault {
FONT-SIZE: 10pt
}
DIV.Section1 {
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
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: ActiveDir-owner@mail.activedir.org 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
Alain.Lissoir@LissWare.Net
Home Page:
http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| listmail
Posts:454
| | 12/03/2006 12:01 PM |
| Oh I see that. On the flip side, companies that produce professional
products like x, y, and zΏ] 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.
Ώ] Names withheld to protect the guilty.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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
cid:609343613@02122006-153C
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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).
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
_____
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| AD000001356
Posts:0
| | 12/04/2006 8:02 AM |
| > 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"
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Ώ] 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.
>
>
> Ώ] Names withheld to protect the guilty.
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] 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
>
> cid:609343613@02122006-153C
>
> Alain.Lissoir@LissWare.Net
>
> Home Page: http://www.LissWare.Net
> Where am I? http://map.LissWare.Net
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] 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).
>
> 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
>
> _____
>
> Alain.Lissoir@LissWare.Net
>
> Home Page: http://www.LissWare.Net
> Where am I? http://map.LissWare.Net
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/
>
>
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/ | | | |
| alainlissoir
Posts:3
| | 12/05/2006 2:50 AM |
| CIL
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Sunday, December 03, 2006 9:01 AM
To: ActiveDir@mail.activedir.org
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Ώ] 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.
[Alain] I understand that and in this regards Vista makes a tremendous usage
of WPP logging and ETW logging (the latter through the event log and the
event log viewer - see analytic channels). You should look at this.
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.
[Alain] There are several points here. First no one is deciding/preventing
non-properly skilled people to write software these days (Under Windows or
any other platform). You can even badly design software on top of the C API
with one difference: The abstraction layer is just easier to figure out.
Because of this you may have people with less programming background
developing some solutions and this creates a situation which is exactly the
downside of the advantage. There are always two faces on a flipping coin and
you cannot avoid that. However, some admins in smaller companies not having
the skills, the budget and the time to write their applications found some
very useful solutions and ways to "automate" certain things without
requiring that background and these people are very happy! I come back to my
point of the WSH success below.
When you design an application, you don't always design it based on the best
technical arguments, the skills of the people and the time available to meet
the business requirements must also be factored in the choice.
Regarding the scalability of the abstraction interfaces, as I said below,
some of them are in the system since NT 4.0 and they were not designed to
deal with a large number of accounts in the way they work. Today they have
to, and some of them deserves a re-design as explained below. For instance,
the NT 4.0 SAM was great as long as servers were workgroup or small domain
servers. Later, expansion of enterprises showed that the NT SAM was not
scalable and many companies have been hitting the 40 MB limit while praying
every day to avoid a SAM corruption. It was even not a situation that was
part of any design during the forecasted NT 4.0 infrastructures. Then AD was
created to overcome this evolution, and of course, some of the interfaces
from that period of time still show limitations. The Win32_Account is an
example. It can be fixed by creating a new design (so, it is not just a bug
fix), but it is a question of creating a new provider design to work
accordingly to the current infrastructure. Again, if this forum thinks it is
important, I will be very happy to support the call in this respect.
Now, how should I read your reply? Do you think that Microsoft should not
provide any abstraction interface and should, instead, only provide low
level API?
If you had the choice, what would you implement to address the need of a
world-wide community of admins that are skilled very differently but who all
have the same goal: Managing Windows with whatever the skills they have.
What would be your solution in this space in an attempt to please everyone?
How would you argue that point?
It was more to get the masses so they could do basic things.
[Alain] Absolutely but not only ... Abstraction layers like WMI make usage
of CIM from DMTF
where the intent is to offer a common semantic
representing management entities, so the entire industry can share the same
schema to encourage interoperability between systems of different natures.
When you want to elevate the interoperability from the level of the API to a
common semantic that can be understood by various systems, you must have
abstraction layers in place to "hide" the specificities. Today, with WinRM
(WS-CIM standard also
available on the DMTF website) on top of WMI, this is a reality as you can
issue WS-Man commands from a Sun system against a Windows machine supporting
WS-Man (WinRM
command in 2003 R2 and Vista). Thanks to abstraction layers to achieve this.
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.
[Alain] I agree there is room for improvement here. But it is the
abstraction technology or the actual design decided that needs to be
reviewed?
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?
[Alain] Well, I will be very happy to make some education to this person.
WMI is useful in asset management, configuration & settings and monitoring.
We have surveys showing this clearly. But again, if the provider design is
not properly chosen, it can fail its purpose which could lead people to
think that this is not the purpose for doing monitoring.
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.
[Alain] If you have concrete examples with repros steps, I will be MORE than
happy to forward the cases to our Powershell and Exchange PMs.
Now, regarding the bandwidth, I don't know how you used it, but have you
looked at the WinRS solution built on top of WinRM in Vista (and LH server)
that can also be leveraged to achieve PowerShell remoting?
It could way better than remote RPC/DCOM WMI requests as you know them today
(while you could still use WMI from PowerShell and/or from WinRM
). I encourage
everyone to have a look ...
Ώ] Names withheld to protect the guilty.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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
cid:609343613@02122006-153C
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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).
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
_____
Alain.Lissoir@LissWare.Net
Home Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org 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/ | | | |
| milburnr
Posts:0
| | 12/07/2006 2:54 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Or sometimes programmers don’t even bother with as much as
vbscript, and instead their VB/C++/.NET programs execute net use commands to map
drives so they can copy files via a batch file as part of the operation of the
program, they copy text files into folders and a service picks up and reads the
text file to run a batch file, and they use an api to write a batch file to the
root of C whose contents are net stop service and net start service. Or
at least this could happen in theory. I’m sure I don’t know anyone
who actually does this. Purely hypothetical you understand.
On a serious note, there’s a lot to be said for vbscripts
that do a certain thing when you might need to do a one-off customization, and
you can just pull the thing up in notepad. I’ve written a few vbs’
and hta’s that I’ve needed to do that with, and I was glad they
weren’t in a compiled exe. Like the store was going to open in 15
minutes and we didn’t have time to do it manually but the script didn’t
work because of this one little thing that made that store different…
and I’m not nearly as good as joe where I can somehow manage to build in
options to every conceivable exception (that’s a compliment, in case it’s
ambiguous, and here is the obligatory smilie J)
Rich
-----------------------------------------------------------------------
Rich Milburn
MCSE, Microsoft MVP - Directory Services
Sr Network Analyst, Field Platform Development
Applebee's International, Inc.
4551 W. 107th St
Overland Park, KS 66207
913-967-2819
----------------------------------------------------------------------
”I love the smell of red herrings in the morning” -
anonymous
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of joe
Sent: Sunday, December 03, 2006 11:01 AM
To: ActiveDir@mail.activedir.org
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Ώ] 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 canwrite abasic
vbscriptbased on these frameworks think they are aprogrammer 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 andto
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 WMIinterface 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.
Ώ] Names withheld to protect the guilty.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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
Alain.Lissoir@LissWare.Net
Home
Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] 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).
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
Alain.Lissoir@LissWare.Net
Home
Page: http://www.LissWare.Net
Where am I? http://map.LissWare.Net
From: |
|
|