This week Microsoft rolled out a BIG hotfix (90 hotfixes) rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1.  To better understand all the goodness it gives you check out the AskPFEPlat blog or go to the source of one of the guys who helped put it together, my fellow PFE Jeff Stokes.  It is being distributed as an enterprise hotfix and so I think it likely that a lot of you folks running SCCM to manage your enterprise might want to roll out this hotfix.  One big advantage that comes to mind is including it in your OSD image capture to cut down on patch install time for future deployments.   The trick is that “out of the box” you can’t deploy this.  It does not sync to WSUS and your SCCM software update point (SUP) automatically.  There are some simple steps you can take to get it there, however.

1. On your central site/CAS SUP open up the Windows Server Update Services admin console
1. It is worth noteing that we see SCCM folks do more harm than good in the WSUS admin console, but this is one of those exception times you need to go in there.  Do so carefully.
2. Go to updates and select Import Updates to launch a webpage to the Microsoft Update Catalog.
1. 
3. Search on 2775511 and then add all that you are interested in getting for your environment
1. 
4. Make sure the checkbox to import directly is selected then hit the import button.
1. Another box will come up tracking the download and show success when completed
1. 
5. Verify that your SCCM site is set to sync "Updates" classification, becase that is what this is (as compared to "service packs" or "security updates").
6. Once that download is complete you can sync SCCM and then you should see the updates in SCCM to deploy as you would any other update
1. 
2. 

3-14-13 update - Added links to AskPFEPlat and Jeff Stokes' blogs along with warning about using WSUS admin console

3-14-13 update #2 - added clarity about fix classification

One of the hardest things to tackle in SCCM these days is client health.  It is an on-going issue because it is hard to diagnose and hard to programmatically fix.  SCCM’s client is much improved over older versions but it still has occasional issues and its dependencies such as WMI and Windows Update Agent still have theirs as well.

While looking into this for one customer I came up with a trick that won’t solve all client health problems, but it moves one step closer.  This trick is for some of the Windows Update Agent (WUA) issues.  If anyone uses this and finds issues or improvements please let me know and I will follow-up or correct this post as needed.

The first step is to identify the machines having WUA issues.  There are probably several ways but what I found useful was to look for clients sending 11416 status messages.  Creating a status message query was easy but creating a collection based on status messages takes a little more work to build.  Here is one I put together that seems to do the trick:

select distinct SYS.Name,SYS.Client from SMS_StatusMessage as stat join sms_r_system as SYS on stat.machinename = SYS.name where stat.ModuleName = "SMS Client" and stat.MessageID = 11416 and DateDiff(dd,stat.Time, GetDate()) <1

This query gets all the machine names that have sent a 11416 status message in the last day and cross references with the system object for that machine so that a collection of machines can be put together.

Once you have your collection of machines identified the next step is to send those machines something to repair WUA.  KB971058 has a nice Fix It script that will do this and you can download it from the KB.  It is an MSI and in my testing using the default settings seemed to be enough to fix most machines.  As an MSI you can have SCCM create your package and program by creating a package from definition and pointing at the MSI file itself.  This should give you a silent run option.

Once you have the package in place advertise it to your collection created based on the query above and see if that solves your WUA health issues.  For my customer we saw a 92% reduction in WUA issues using this method.

** Correction** I had previously posted this as a WMI fix, when this is really a WUA fix.  I just had WMI on my brain.  My apologies for any confusion.

This is one of those little known tricks of SMS/SCCM, but it can be handy.  I often run into customers who have SMS 2003 and their collection management is out of control for various reasons.  When going to SCCM they want to clean up their collections.  Deletion is the easy way to do that, but doesn’t work in all situations.  Here is how you can move a collection (or collection hierarchy) under another collection.

Let us say you have two root level collections named “parent” and “child”.  You want to put “child” under “parent”.  Child may or may not have other collections under it already.  To move child you would start by accessing the right-click menu on “parent” and choosing a new “Link to collection”.  In the dialog that comes up choose “child” and complete the dialog.  This will now put a copy of “child” under “parent”.

Notice the collection ID for the sub-node “child” is the same as the root-level “child.”  They are, essentially, one and the same so any change made to one, such as membership rules, will effect the other.  There is one exception however, deletion of the collection.  This is where your “collection copy” turns into a “collection move.”  Not that “child” is under “parent” you can delete the original root level “child” and the new sub-node “child” will not be deleted.

TaDa… collection moved!

One of the things I often get asked to do is to look over ConfigMgr 2007 installs and provide feedback on any issues I see.  One of the things I look at is the folders in \Microsoft Configuration Manager\Inboxes.  These folders contain all the activity of ConfigMgr and typically consist of files which are coming and going.  However, some times things go wrong and a bunch of files can start accumulating in these folders, eventually running you out of disk space.  This is never good and you should look into the root cause to fix it before worrying to much about the files themselves.  However, some things fix themselves, or some files are left behind after fixing the problem, and those problems are a nuisance that needs to be cleaned up and removed.  I will try and provide a list of some of the folders I look at and recommend cleaning up if there are old files in them.

I should make a note here that while you can just delete the files, and will be fine in most cases, it is a good practice to instead move the files to a temp folder long enough (a day or week) to make sure there are no negative repercussions from the file removals.  It is just smart to play it safe.

• Compsumm.box – This is for component summarizer messages.  If you have old stuff, it may not be relevant any more so remove the files.
• CIAMgr.box – Configuration items, probably related to patches but perhaps for other things.  If the files are older than a week, they have probably been forgotten and can be removed.
• Auth\dataldr.box\badmifs – Hardware inventory that was bad for some reason.  Often times the bad file will be a temporary thing and the system will self correct, leaving files behind.  Once you have investigated and solved the reason it is bad, feel free to remove the files.
• Hman.box – Don’t touch stuff in the subfolders, but if files in the root are old, site communication probably had a hiccup at some time and the files can be removed.
• Sinv.box\badsinv – Software inventory gone bad, similar to the dataldr.box\badmifs.  Remove files once any investigation is done.
• Statmgr.box – These are status messages and old files can be removed as they are probably no longer relevant.
• Auth\statesys.box\corrupt – Old status messages here should be removed .  They are probably out of date anyway.
• Auth\ddm.box\regreq\bad_ddrs - These are discovery records that couldn't process for some reason.
• Colleval.box - old .CEP files may become orphaned and can be safely deleted if older than a week

There are lots of inboxes, and I’m sure many of them also get file backlogs for various reasons.  these are just the ones I see most often.  As I see and validate them I will update this list as appropriate.

For a good list of all the inboxes and their purpose, see this technet article.

7/29 update - Added CEP files

I was working with a customer once and we were looking for a good way to separate laptops from desktops within Configuration Manager when we hit upon this little known “memory” trick that I wanted to share.

Often times people use the Win32_SystemEnclosure class and look up the chassis type.  While this is a good, and accurate, way to do it the fact that you have to parse all the possible outcomes to then group into “laptop” and “not laptop” is a little bit of a pain.  An alternative method that we found is to use the Win32_PhysicalMemory class instead.  In there is a property called FormFactor that can be put to use.  We found that a value of 12 would indicate a laptop.  12 means that the memory in the machine is SODIMM, a memory used almost (but not totally) exclusively by laptops.  While this isn’t as fool proof as the system enclosure, I suspect that it will work for most of you out there who are trying to differentiate laptops from desktops in your ConfigMgr inventory.

There is one downside, which is that the Win32_PhysicalMemory class is not collected by default as part of your hardware inventory.  Adding it is easy enough though, just modify your SMS_DEF.MOF and off you go.