Sorry, AFAIK there is no workaround, and even worse, I remember seeing this 
class contacting every trusted domain and enumerating the accounts there too, 
so this WMI class is one to normally stay away from, so "Not Optimized" is the 
understatement of the year :)
 
Thorbjörn Sjövold 
Special Operations Software 
www.specopssoft.com 
thorbjorn.sjovold a t specopssoft.com 

Download our free tool for remote Gpupdate with graphical reporting, 
http://www.specopssoft.com/products/specopsgpupdate/default.asp 


________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Friday, December 01, 2006 3:49 PM
To: [email protected]
Subject: [ActiveDir] 100% CPU utilization when querying Win32_Account on DC


 
Hi all,
 
Recently I had a case where we experiences high CPU utilization after deploying 
SMS client to DCs.
By now we have identified that the issue was caused by an extension of 
sms_def.mof file containing the definitions of information that should be 
collected from the agent.
 
The interesting part is that I was able to reproduce the behavior without SMS 
agent. Just execute the following WMI query on your DC and see the CPU spikes 
to 100% and will stay there till you kill the wmiprvse.exe process:
select * from Win32_Account where LocalAccount=True and SIDType=1
 
Now you do not need to explain to me that this is damn stupid to run this type 
of query on a DC, yet I would expect the DC to be able to handle the query, but 
what I see is that the query never returns - it just hangs there choking up the 
CPU till you kill the WMI process.
 
Almost the same behavior is observed when executing "wmic useraccount" from the 
command line, but in this case the query does return the results after a while 
(~2-3 minutes on ~2K user account AD).
 
The only thing related to the issue that I was able to find is the following 
KB: http://support.microsoft.com/kb/268715 
("WMI Query Support for Win32_Group Is Not Optimized") where the following 
query "SELECT * FROM Win32_Group WHERE Domain="workgroup" AND Name="smith"" 
causes the identical behavior. But folks, we are talking W2K3 with SP1 and not 
W2K pre-SP2.
 
Any chance anyone has stumbled upon it ? Is aware of hotfix ?
 
Thanks,
Guy
 

Reply via email to