Oh I see that. On the flip side, companies that produce professional
products like x, y, and z[1] etc should have the skill sets to produce
more
efficient and directed applications that don't have a reliance on those
abstraction layers and use the more efficient APIs in ways that are
directly
relevant to the goals of the applications and that they have a greater
understanding of. Obviously someone may not have a super strong
understanding of the core APIs but at least there is only a single level
where problems can be introduced versus the multiple levels that can be
introduced in the abstractions such that you have to try and figure out at
what level the issue is at. Possibly if the abstraction layers had amazing
logging that could be enabled to track issues and explain what they are
translating the requests to at the lower levels it might be easier for
someone to identify where the issue cropped up.
One issue I see is someone who can write a basic vbscript based on these
frameworks think they are a programmer and start producing tools that they
sell. They have no understanding of the underpinnings of the overall
system
and quite frankly, to scale things up, they really ought to, the
abstractions are not great in that arena and to be fair, I don't believe
they really were designed to be. It was more to get the masses so they
could
do basic things. Another issue I see is when someone only published say a
WMI interface into something. I have that issue with Exchange 2000/2003 as
they really did a poor job with a lot of that from being poor performers
to
not performing correctly at all. I took this up with the Exchange PSS
Support folks and finally got the great answer of WMI isn't designed to be
used for monitoring... How do you argue that point? Unfortunately the only
other recourse is to try and work through completely undocumented MAPI
stuff
and MAPI is already painful and sucky at best though it was designed to be
a
nice abstraction layer to make lives easier. MONAD for Exchange is
supposed
to fix that but I am expecting tremendous scaling issues in the
environments
I play in with it and quite frankly have even admitted that I would rather
see WMI as it doesn't saturate the network lines passing data that isn't
being requested.
[1] Names withheld to protect the guilty.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir
Sent: Saturday, December 02, 2006 6:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account
on
DC
You must take into account that not everyone is a Win32 API or LDAP API C
or
C++ developer to write its own logic and create its own tool to perform
the
management task their business requires.
Abstraction layers like WMI, ADSI, CDO, XMLDOM, WSH, ADO and so on ... are
helping thousands of people to write scripts and applications without
having
to dig into the API programming level.
Both worlds have pros and cons.
The API programming level requires a more specific programming knowledge,
the abstraction layers introduce a proxy, simplifies the access pattern
and
obviously have a performance cost.
I think that none of the two worlds have to be rejected, they just need to
be used correctly and when appropriate. This why Microsoft is documenting
Win32 API, COM interfaces and .NET API.
If the COM abstraction layers were that yuck, programming environments
like
WSH and/or VB6 would have not been so heavily used and successful.
Are abstraction layers perfect? Clearly not. Are they useful? Yes for
sure.
Is there room for improvement? Always.
Regards,
/Alain
Alain LISSOIR
<blocked::http://www.LissWare.Net> cid:609343613@02122006-153C
<mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
Home Page: http://www.LissWare.Net <blocked::http://www.LissWare.Net>
Where am I? http://map.LissWare.Net <blocked::http://map.LissWare.Net>
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Saturday, December 02, 2006 1:33 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account
on
DC
Good post but yuck. Amazing how many issues you avoid by avoiding ADSI,
WMI,
CDOEXM, and the other MSFT frameworks designed to make life "easier"...
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alain Lissoir
Sent: Saturday, December 02, 2006 12:37 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account
on
DC
Let me step in here to give you some more background ... J
WMI is a 3-tier architecture (See figure at
<http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_architecture.asp>
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_architecture.asp).
The SMS client runs at the level of the client API (3) and submits the WQL
query to WMI at layer 2 (Core WMI service).
This query is handled by WMI core. WMI Core looks after the class in the
WQL
query (i.e. Win32_Account) and locates the provider supporting it.
In this case, the provider is CIMWin32 implemented by CIMWin32.DLL (I skip
the explanation about how WMI does that unless someone is interested).
Because that CIMWin32 provider does not support WQL query parsing and is
not
handling them by itself, WMI core takes the initiative to actually
converts
this query into a full enumeration request to the provider, meaning that
the
provider is actually building ALL instances of Win32_Account with all
their
characteristics. Once the collection is built, WMI core receives the
result
set and is then post-filtering the enumeration set to match the WHERE
clause
of the WQL query, which in turn returns the result set requested by the
client (SMS in this case). This is the way how WMI core works with all WMI
providers not supporting WQL queries natively (I mean supporting query at
the level of the provider itself). Actually, this enumeration technique is
implemented to support WQL queries even for providers not supporting WQL
queries in their code by design. A WMI provider may have many capabilities
(i.e. Get, Put, enumerations, events, etc) and one of them is to support
WQL
queries (which actually is off-loading WMI core do to the job I just
described).
This explanation does not solve your issue, here, but it gives you the
explanation of the "why" where the actual solution is to implement a WMI
provider that supports natively WQL queries and actually performs the
right
SAM or LDAP queries against AD (I mean properly scoped). It would be a
sort
of WMI provider converting WQL queries into SAM/LDAP queries to put it
short.
This class was created way before AD did exist. The presence of AD
increases
dramatically the number of accounts available. Although this class with
this
provider was working fine during the NT 4.0 time (yes, this class dates
from
that period), it is challenged in large AD infrastructure, Make a test
with
a small AD infrastructure where you have only 2000 accounts, and
everything
will be fine. I can bet that your AD installation is way bigger ...
Now, if you use WMI a lot to query the SAM and AD and if you feel this is
an
area where some enhancements can be made, let it me know and I will be
pleased to communicate this data point to the team in charge of WMI and
the
team in charge of Active Directory, So, we can let them know that it is an
important scenario to enhance and support better. No commitments here, but
I
will be pleased to convey the message.
Hope this helps a bit ...
PS:
However, if you feel you have WMI issues, you can always use the WMI
Diagnosis Tool 1.0. You can find pointers to it (+Webcast) at
http://www.lissware.net.
Note, we will release the version 2.0 early next year.
Regards,
/Alain
Alain LISSOIR
<blocked::http://www.LissWare.Net> cid:114265316@01122006-02BE
_____
<mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
Home Page: http://www.LissWare.Net <blocked::http://www.LissWare.Net>
Where am I? http://map.LissWare.Net <blocked::http://map.LissWare.Net>
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Friday, December 01, 2006 7:36 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] 100% CPU utilization when querying Win32_Account
on
DC
Thanks Susan, but I think this case is different - we are talking about
different WMI class and in my case the query hangs and never returns
results. The ITMU issue is probably a result of intensive load on the CPU
when performing the query you pointed to, but in my case if I let it run
for
hours it still never finishes.
I am far from being well versed in WMI, but I'd suspect that here the
problem is caused by WMI not using paging in the query or very inefficient
processing when using both LocalAccout=True and SidType=1 keys.
Guy
________________________________________
From: [EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka
Ebitz - SBS Rocks [MVP]
Sent: Friday, December 01, 2006 5:12 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] 100% CPU utilization when querying Win32_Account
on
DC
http://www.myitforum.com/articles/8/view.asp?id=9048
http://www.myitforum.com/articles/8/view.asp?id=9284
Rod's been tracking that on myitforum and the Patch management listserve
for a while now.
Guy Teverovsky wrote:
Hi all,
Recently I had a case where we experiences high CPU utilization after
deploying SMS client to DCs.
By now we have identified that the issue was caused by an extension 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/
