Free Disk Space Collection SCCM 2012

We have been having several users with older PC's complaining of low disk space errors.  These are normally shared Dell PC's with 80GB HDD's.  We have lots of surgerys where tens of nurses will log on and subsequently create a local profile.  As we have cached mode enabled for Outlook (don't ask) this creates massive .OST files in every profile.

I wanted SCCM to keep track of these machines and subsequently run a batch file that clears all the .OST files off the machine.

I wanted a collection that would list all machines with less than 1GB free disk space.  I created the collection courtesy of http://myitforum.com/myitforumwp/2013/12/09/sccm-2012-r2-free-disk-space-report/ but found it was empty no matter what.

I then eventually came across this post http://e-enfra.blogspot.co.uk/2012/02/sccm-2012-free-disk-space-is-not.html instructing that by default the disk space isn't automatically collected by the hardware inventory cycle.

Enable this and just wait for the Harware Inventory Cycle to kick in and the disk space info will become available.

Operating System Deployment with USB Dongles (Lenovo in my case)

With the advances in technology we have seen in recent years, devices have become smaller, thinner and lighter than ever before.

With this we are finding that some devices are loosing functionality - ie. Some devices are having ports omitted to retain their slender profile.

The Lenovo X1 Carbon adopted this approach and required a USB dongle which I posted about the pitfalls of PXE boot here: Lenovo X1 PXE Issues

I've seen an increase in the issues these dongles are causing us deployment techs, one of those being that each of these dongles have their own MAC address.  In true tech style when we see this new wizardry the first thing we say is "MINE"... Well actually the first thing we normally say is "Ooh Shiney" but then there's a Smeagle like "My Precious" when we claim the Shiney as our own.

I did this.  I had my very own dongle.  It worked great.  ONCE!  Every subsequent build failed.  I did a bit of research and found that it had it's own MAC that was registering in SCCM so I had to surrender my Shiney and give it on to the user.

I now use the supplied dongles for each build as it isn't worth the trouble but I have it on good authority that with the latest gen of Lenovo kit they are shipping certain models with on-board NICs (therefore unique MACs) and the dongle is purely a port extender utilising USB to present an Ethernet port.

If you have fallen prey to this (and insist on using one dongle to rule them all) you need to read my earlier post to search SCCM for machines by their MAC address.

Have fun...

DocN

Collection for MAC Address

If you are having issues with machines being renamed and need to locate it in SCCM why not try searching by MAC address?

Use this query and just adjust the MAC accordingly:

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System where SMS_R_System.MACAddresses = "XX:XX:XX:XX:XX:XX"

SCCM Collections not updating - eggtimer displays

I've had a problem with the old girl recently - our SCCM 2007 environment had been chugging along nicely until a few weeks ago.

We have approx. 500 collections with update schedules running pretty evenly throughout the day.  As I'm sure you will agree the annoyance of the the old Update Collection Membership and then refresh the console is a blight on our day - but when that little red eggtimer WILL NOT DISAPPEAR it sends my SCCM OCD twitching and I just cannot carry on with my day until I've sorted it...

 

I've done a fair bit of Googling and not really found that many comprehensive solutions to this other than those that point to the Microsoft KB982400.  I was checking the Colleval.log and kept seeing Checking collection: 0x18, EvaluationCRCChanged=FALSE, ScheduleCRCChanged=FALSE, AwaitingRefresh=TRUE - which is fine, yes it's awaiting a refresh - SO REFRESH ALREADY!!!!

The D:\PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes\COLLEVAL.box seemed fine and the BADRELP and RETRY folders were empty - so what was causing this???

Finally I spotted a few references to AV related issues (which I suspected were responsible for another issue I have with slow PXE boots).  Sure enough, when I killed off all the Trend related services from Windows Task Manager and did another update and refresh of the collection - IT WORKED!!

Trend Services Running on the SCCM Server

I've since added an exception to Trend File scanning for the PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes folder and I've noticed a considerable improvement - I'll post back after a week or so to let you know how it's going.

Hope this helps someone else...

DocN

***UPDATE***

It seems the actual problem here was down to the sheer volume of collections running updates.  There was a cumulative effect of the schedules and come 1pm the collection action list was backed up with about 3 hours of updates pending.

I've gone through and removed all update schedules from our collections (yes - it was a lengthy monotonous task) and all is well.