We all know (or will now) that if a client misses a mandatory advertisement in ConfigMgr for whatever reason, e.g., the client is powered off, it will happily “run” the advertisement as soon as it can once it comes online again. Similarly, if a client receives an advertisement with a schedule in the past the client will “run” the advertisement as soon as it can. But what happens when the advertisement has a recurring schedule? I rarely use them, but every once in a while, behavior for this scenario is queried on the forums or at a client.
Test #1 Set up
A simple batch file that appends the time and date to a text file:
echo %date% %time% >> c:\RecurrenceTest.txt
I advertised this to a client and set a mandatory recurring schedule of every 15 minutes.
The Result
Here are the contents of the output file:
Thu 09/09/2010 15:31:00.53
Thu 09/09/2010 15:46:00.53
Thu 09/09/2010 16:01:00.54
Thu 09/09/2010 16:16:00.54
Thu 09/09/2010 16:52:06.38
Thu 09/09/2010 17:00:00.19
Thu 09/09/2010 17:15:00.21
Thu 09/09/2010 17:31:00.53
Thu 09/09/2010 17:46:00.48
Thu 09/09/2010 18:01:00.49
Thu 09/09/2010 19:07:16.15
Thu 09/09/2010 19:16:00.54
Thu 09/09/2010 19:31:00.48
Note that there are two highlighted breaks above: the first was an OS power down and the second was a VM pause.
The first observation is that the client does “catch-up” a single recurrence of the advertisement -- but only a single recurrence. This catch-up is out of band meaning that it doesn’t occur on the 15-minute mark. It occurs as soon as the client realizes that it missed an occurrence.
My second observation is that when I was logged out of the client after the power up, the occurrence happened one minute sooner. This is because I had a one minute countdown set on the advertisement but this one minute countdown is only applicable when a user is actually logged into the system. As soon as I logged back in, the one minute offset returns.
Test #2 Set up
Same as above with a different VM added to the same collection using the same advertisement which has a start date in the past.
The Result
Here are the contents of the output file:
Thu 09/09/2010 18:07:45.23
Thu 09/09/2010 18:16:00.89
Thu 09/09/2010 18:31:02.65
Thu 09/09/2010 18:46:01.17
Thu 09/09/2010 19:01:02.42
Thu 09/09/2010 19:16:00.89
Thu 09/09/2010 20:07:19.60
Thu 09/09/2010 20:15:00.45
Thu 09/09/2010 20:30:01.79
Thu 09/09/2010 20:46:02.40
Thu 09/09/2010 22:05:27.29
Thu 09/09/2010 22:16:00.28
Thu 09/09/2010 22:31:01.72
Thu 09/09/2010 22:46:04.04
Thu 09/09/2010 23:01:04.05
Same results here with the two gaps highlighted in yellow: the first one being an OS shutdown and startup and the second one being a VM pause. The only thing different here is the initial catch-up highlighted in blue – this happened because the start-time of the recurrence pattern was before the client received the advertisement and was thus in the past.
One other quick note, these catch-up executions of the advertisement look exactly the same as other executions in the logs so there will not really be a way to tell them apart except by closely comparing their execution times.
Conclusion
Clients will always execute missed advertisements including a single occurrence of an advertisement with a recurring schedule.
Server Core is an interesting “edition” of Windows Server 2008 and 2008 R2 that offers some potentially nice benefits: http://technet.microsoft.com/en-us/library/dd163517.aspx. Because of these benefits, many folks have started using Server Core in their enterprise but how can we start inventorying which systems are server core and which are not. This question lead me on a quick web search on how to find this info in WMI – we all know that WMI is ConfigMgr’s best friend right? This brought me to the Win32_OperatingSystem class and the OperatingSystemSKU attribute: http://msdn.microsoft.com/en-us/library/aa394239.aspx.
Upon reviewing sms_def.mof to see if this attribute is being collected or not, I discovered that the attribute is not even specified in sms_def.mof. Adding it to sms_def.mof is as simple as adding the following highlighted line to the Win32_OperatingSystem class definition though:
[SMS_Report (FALSE) ]
uint32 NumberOfProcesses;
[SMS_Report (FALSE) ]
uint32 NumberOfUsers;
[SMS_Report (TRUE) ]
uint32 OperatingSystemSKU;
[SMS_Report (TRUE) ]
string Organization;
[SMS_Report (TRUE) ]
uint32 OSLanguage;
[SMS_Report (FALSE) ]
uint32 OSProductSuite;
[SMS_Report (FALSE) ]
uint16 OSType;
Make sure that you check dataldr.log for a success code on the site server after you modify the sms_def.mof to make sure that you haven’t mis-typed anything.
After each system refreshes its policy and performs a hardware inventory, you’ll be all set to use a simple query like this:
select SMS_R_System.Name, SMS_R_System.OperatingSystemNameandVersion, SMS_G_System_OPERATING_SYSTEM.OperatingSystemSKU from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId
This query results in following in my lab:
The valid values for OperatingSystemSKU are listed at http://msdn.microsoft.com/en-us/library/aa394239.aspx. For my results above, 10 is Enterprise Server Edition, 4 is Enterprise Edition, and 13 is Standard Server Core Edition. Note that according to the documentation, this attribute only exists on Windows 6.0+ systems, i.e., Vista, 7, 2008 and 2008 R2, and thus MININT-KPGASIQ, which is a Windows XP system, cannot populate this value. Make sure that you take account of these NULL values when crafting your queries.