Slow Windows 7 PC with SCCM - WMI...?

Question

Hi All,
We use System Center Configuration Manager 2007 R3 to provide on demand applications and software metering to Windows 7 SP1 X86 (we use <acronym title="Windows Server Update Services">WSUS and WDS </acronym>entirely independently
of SCCM 2007 R3).
This year, we had a progressive slowdown of PCs.  I've eliminated hardware, software, networking, the base image, home directory shares, <acronym title="Windows Server Update Services">WSUS</acronym>/updates, etc.  Users don't
have admin rights.  If I deploy an identical image into a .VHD on the same physical computer (using native .VHD boot), it performs as expected.  With hardware, networking, AD, etc being identical, This leaves with applications and printer drivers.
We did discover the service hosting WMI was very busy, then discovered the WMI database
C:\Windows\System32\wbem\Repository\OBJECTS.DATA
was large - 500Mb.  (by contrast, out-of-the-box Windows 7 SP1 x86 is about 15Mb).  Microsoft's WMIDIAG
Download The WMI Diagnosis Utility -- Version 2.1 from Official Microsoft Download Center considers +300MB as very large.
Sure you're all familiar WMI is queried by and published to by lots of different parts of the system; slow WMI, slow system.
We have some PCs with SSDs, but the WMI file is some sort of database that I don't think was ever engineered to scale to these sizes.  Hence even a fast physical disk won't resolve this.
I've been doing some deeper analysis based on
Troubleshooting WMI Repository Bloat - System Center Blog by Russ Slaten - Site Home - MSDN Blogs
Troubleshooting WMI Repository Bloat - System Center Blog by Russ Slaten - Site Home - MSDN Blogs
I've gathered some data and wondered if I could share it with colleagues, with the hope that if I show you mine you'll show me yours...
Have put up my own data, and methods to gather the data, at
http://sdrv.ms/15VGdUM
Would *really* appreciate replies.  Am not familiar with this stuff, and only done it at my current employer, so I have no "context" of what's OK and what's not.
Thanks in advance.
Kind regards,
Anwar

Answer 1

Hi Jason,
Thanks for your reply.  
We have a large fleet of PCs.  On 4 of them (in fact, the 4 from the spreadsheet!) I
 - applied KB2775511
 - configured WMI to run in a separate process (as recommended by a Microsoft SCCM guru - forget who, where and when)
 - initiated a reset of the repository (winmgmt /resetrepository) (as NOT recommended by a Microsoft SCCM guru - forget who, where and when, but which appears to be common (routine?) practice; we've also observed Windows PCs will do this themselves
when they've decided enough is enough).
 - waited while SCCM 2007 R3 client relearnt about all of the advertisements (300+ advertisements, but because each may contain multiple programs, the CCM_SoftwareDistribution class has in excess of 700 records).
I've configured the computers to 
 - logon
 - wait 60 seconds
 - restart
and repeat this endlessly with a set of 5 different IDs each.  I did this before and after the actions I mentioned above.
I'm using a simple metric - how long from the previous logoff to the current logon (as recorded by actions performed in logon/logoff scripts.  This is a good metric for us because it covers the "Please wait..." [startup] and "Welcome" [logon] delays
that most affect users.
I saw average improvements of about 10 seconds on two of the PCs, and around 90 seconds on two other PCs.  Which is definitely good!
HOWEVER, this isn't very dissimilar to re-imaging the PC, which I *know* resets performance back to "acceptable".  I expect performance to degrade again.  However, I don't know precisely how or when or why.
I discovered that each user logging on to SCCM-managed PCs will get their *OWN* set of WMI classes [not just records - actual classes, whose name includes their RID] created.  As a University, we provide a set of PCs for many thousands of students to
use at "random".  Our most popular PCs may have hundreds of different students logging on.  Their WMI repository will accummulate large numbers of WMI classes.
I've since discovered that we perform a hardware and software inventory everyday. I don't think this will be helping.
Under the hood, it seems that
 - the SCCM server hosts policies, and the server will evaluate the *actual* set of policies to apply to each PC (taking into account inheritance, exceptions, ACLs, WMI filters, etc, etc, etc) 
 - the SCCM client will replicate these policies locally
 - the SCCM client will then endeavour to implement these policies, keeping a record of results in WMI
 - the SCCM client will replicate results back to the SCCM server
Hence the SCCM client (itself - excluding servers) appears to be, in effect, a 3 tier application server in itself
 - the database tier is provided by WMI
 - the application tier is CCM Exec
 - the database and application tiers are available via the WinRM service
 - the client tier is more-or-less Windows itself
These are merely my observations of what I've uncovered over the last few days.  I could be completely wrong :-)
Kind regards,
Anwar