Resolving the Last of Our DST Issues

Per my previous post, we think we've resolved most of our DST issues.  Overall, we had three problems, and three solutions.

1) This is the big duh!  If you don't run all 4 steps of the process, things will go wrong.  Solution: follow the plan!

2) For reasons unknown, in a few cases, our "push" of the updates didn't work.  We're not sure if this was something coded badly in ScriptLogic, or some weird permissions, or what, but on a very small number of systems, the updates didn't all "take."  Solution: we visited the errant systems and ran things manually.

3) The above steps should have been a 100% solution.  But, life just isn't that simple.  We have a very small number of systems (including my notebook!), where despite applying the patches and running the tools, there were still some calendar items in the "new" DST time that were off by an hour.  It just didn't work!  Now what?  Well, fortunately, Chris McGuffin reads better than I do and he already knew of the solution!  For any system where calendar items are wrong even after the patches and utilities, here's the solution:

1. Make sure the user is a Local Administrator and log in as the user
2. Manually change the machine's time zone!  We're in Eastern, so I changed to Central.
3. Rerun the TZmove.exe utility.  (and clear the check-box to re-send all the meeting requests)
4. Now, manually change the machine's time zone back to where it belongs.
5. Run TZmove.exe yet again (and once again clear the check-box)

If you get the same results I did, all will now be fine.  And, if you're the over-protective (or network Nazi) I am, then be sure to remove the user from the Local Admin group.

Comments

[Austin]

Tony, we are having issues with the public calander. Any thoughts on this? Our public calander is all off and I cant seem to run these same steps on Exchange Public calanders.
Austin

[Tony Dye]

Austin => To run the utility against the Exchange Server, you need to use an account with rights to *everything* in Exchange. That's most likely not just your "normal" Administrator account, but instead your Exchange Administrator account. (alternatively, your backup account might work)