SCCM SP2 with R3 WOL Scheduling affected by DST?

I’m seeing a problem in that any scheduled start time for an advert configured for WOL isn’t causing SCCM to generate WOL packets until 1 hour later.  This seems the complete opposite to a fix made available for SP1 (included in SP2) where machines would be awoken 1 hour earlier than the schedule!  What on earth is going off!

Turning on verbose logging for the SCCM WOL components and examing wolmgr.log shows that, allegedly, SCCM ‘Will consider local DST bias of -60 minutes when calculating seconds to wait for further processing” – however, whatever that means, it certainly isn’t resulting in WOL packets being generated 5 minutes before the scheduled mandatory start time.

My server is set to (UTC) Dublin, Edinburgh, London and ‘Automatically adjust for DST changes” is enabled, so I see the correct time at the server and the SCCM log files all show the right time.  If I turn off the DST adjust and set the time manually, the SCCM logs show +1 hour ahead!?

So at the moment, my only recourse is that approximately during March to November the scheduled time for installation to occur via WOL is to be set 1 hour prior to the actual time desired.  That seriously can’t be right!

Advertisements

Automatic Updates behaviour during Task Sequenced Windows 7 Build

I’ve come to the conclusion that whilst in the Post-Install phase of a Task Sequence, it’s probably not a good idea for the machine being built to go swanning off to Windows Update and start automatically applying minor updates.  As well as undermining the whole concept of centrally managing updates – it throws up the risk of upsetting your ‘Install Software’ task sequence steps as they fight for Windows Installer time.

Thus, I find myself trudging with my wading gear into the murk of the unattend.xml file to yet again change what I feel is behaviour that just shouldn’t be switched on by default.

The setting we are concerned with is the “ProtectYourPC” option in the “x86_Microsoft-Windows-Shell-Setup_neutral” section.  We change this to have a value of “3” which effectively turns off the automatic nature of Windows 7 so that our build can complete exactly as per the plan.  Corporate Group Policy settings come down to lock down the behaviour of Windows Update when all is finished.