I'm Robert Marshall, director and principle consultant at SMSMarshall Ltd, who's specialism is in the Microsoft System Center 2012 Configuration Manager product and all of its dependent products, covering all aspects from Architecture, Implementation, Migration to Break-Fix.
I've been in front of computers for over 30 years now, with my roots in programming 8 bit computers, I've taken an often exciting journey which has led to becoming an expert in an enterprise product. I consider my career as starting 17 years ago, when I began my first serious role as a deployment engineer. I've seen 8 bit through to 64 bit, the rise and refinement of the interface we take for granted now, the rise of the Internet from land-line based modem access for the few, to the powerful broadband connections we have today for the masses, I saw mobile phones come into existence, and I've seen Microsoft evolve from more than a handful of employees to the company it is now, while pretty much tinkering with every OS they have released, as well as seeing an industry that has evolved around those humble beginnings to become what we have today. I'm a keen technical puzzle solver, I love to solve gnarly problems around my area of specialism. And, I love to share when I have time. I hope you enjoy the blog.
Configuration Manager 2007 RTM\SP1 has a wee bit of an issue dealing with GMT dates that are offset by DST. Essentially if you are in a DST timezone then the DST offset is not factored correctly, resulting in Wake On Lan (WOL) packets arriving at the destination machines one hour earlier than intended\expected.
There is a work-around, but it simply involves shifting the start time for the advertisement forwards one hour ahead of when you plan to deploy. Not an elegent work around, as all you are doing is moving this one hour window forwards.
If you've been struggling with this one for a while, then you're going to have to wade on until after DST finishes for your timezone, unless of course Microsoft releases a hotfix before the next scheduled service pack release ;-)
Here's a handy link to countries that are currently in DST, and when they revert back to normal. Once DST is behind us, problem is gone.
Got a tip for you ... once DST has finished, SERIOUSLY consider performing a Hardware Inventory on those clients that reside within the timezone that has just come out of DST (keep in mind if you're spanning multiple countries ...). If you have a 1 week HINV schedule then these clients will still be considered to be within DST, at least until their HINV is processed and the clients timezone information is updated in the site servers database. You should be able to guess why this speeds things up. Essentially, you could leave things alone and put up with the DST\WOL issue for a short time longer (depends on your HINV schedule frequency), it's just if you want to make sure your clients wake up in time once they come out of DST.