I'm Rob Marshall, a consultant who specialises in the Microsoft System Center Configuration Manager product. I like to share, i do so by blogging and helping out when I can in the MS SMS newsgroups and participating in the ConfigMgr MVP program.
I was awarded and joined the program in 2009. It'd be an understatement to say it has to be one of the best experiences an IT engineer can have, if they really enjoy specialising in a product.
My biggest weapon for troubleshooting is, my formidable knowledge, no, only joking, you, the community. I find if I cannot answer a question, then I can usually find the answer from using Bing\Google, pouring over the documentation, and if that doesn't work, tinkering in mine or someone elses virtual lab.
The blogs pretty much about ConfigMgr, but it is also a platform for me to express my random urges to display something I've stumbled across, and that I imagine would entertain you or what not as equally as it did me.
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.
Patched: support.microsoft.com/.../944542