Like most things Systems Center Configuration Manager, I'm sure there is a perfectly logical reasons for why things are the way they are but as a lowly technician I am also sure I'll never understand why.
I checked using the Policy Spy from System Center 2012 R2 Configuration Manager Toolkit and again verified that, yes I am getting the two Maintenance Windows that I expected to find except that F51051BF
starts one hour earlier than it should:
If I correlate that list with all of the available Maintenance Windows I find the ServiceWindowIDs of the exact Maintenance Windows I expect to see and while the it's clipped off in the screenshot F51051BF
does indeed begin at 20:00:
SELECT * FROM v_ServiceWindow
ORDER BY ServiceWindowID
What about a machine that has the same Maintenance Windows that is working as expected (i.e., the Maintenance Window is starting at 20:00):
Biggest Active Service Window has ID = {F51051BF-90E8-4ED7-BA06-F74F9E74A098} having Starttime=3/5/2015 7:00:00 PM ServiceWindowManager 3/5/2015 10:00:00 PM 68400 (0x10B30)
Wait WUT? That line was from another client's ServiceWindowManager.log and it certainly believed that 19:00 was the appropriate time to start. I checked a few others. Guess what. Not a single mention of F51051BF-90E8-4ED7-BA06-F74F9E74A098
starting at 20:00... but if I look at the what is listed in the database AND in the Configuration Manager Console the Thurs. Night Maintenance Window is listed as starting at 20:00.
Zoinks! It's not a mystery maintenance window! It's a masked maintenance window!
It looks like that for whatever reason F51051BF
is configured to start at 20:00. The Configuration Manager Console reports that and so does the database but if I look at a handful of clients some go 19:00 and others at 20:00.
Two WAG (Wild Ass Guesses): 1) We have old Machine Policies hanging around from a previously implemented ConfigMgr 2007 Site. or 2) the Maintenance Window policy got changed from 19:00 to 20:00 at some point and the not every machine got the news. Whatever. I have no idea what I'm doing here.
Resolution
I created a new Maintenance Window to replace F51051BF
and assigned it to the appropriate Collection. I waited an hour or two for the clients to do their policy pulls and guess what:
Service Window with ID = {D047CD9F-25E4-4EDC-95E3-44E971E234FA} having Starttime=3/19/2015 8:00:00 PM ServiceWindowManager 3/16/2015 12:13:41 PM 15500 (0x3C8C)
Mystery solved? Not really. Problem solved? More or less...spooky huh?
Best Answer
That kind of task would bedone more often with SCOM (versus SCCM). I don't think you can get an official SCCM alert in the monitorign console, but I can think of a 2 ways to do it with SCCM.
First would be to create a Query for devices that meet the criteria. No alert would be sent, you would have to review the query members every so often. If you have reports for free space, you've probably already done this, but for other readers, you also need to enable the Client Settings/Hardware Inventory collection of the Freespace property from Win32_LogicalDisk (see screen). Set the query to limited by the group/collection in question. The Query select would be as follows:
The second menthod could be done via a Pacakge where you create a Program that is a Powershell sript, and schedule it to run once every 24 hours. This would send an actual email. Deploy the package to the group/collection in question.
With such large disks, percentages are somtimes not always ideal triggers, you could also trigger with an absolulte size like this
if ($diskC.gbFree -lt 1) {