Posted: 2/24/2007 9:33:59 PM EDT
|
Soooooo... Anybody else notice yet that the GPO instructions for this article don't work? support.microsoft.com/kb/914387 The control panel call that the VB Script makes in order to refresh the current timezone information fails, even though the log entries indicate that it succeeded. This is so much fun. |
|
The patches that came out for this DST update totally fucked up 3 of the programs that we use at work daily... totally killed them. Wasn't even able to run them! Ended up uninstalling all of the DST patches and blocked them on the network. Until the software companies release patches so their stuff works with the DST, we won't be installing the MS patches. -d |
We have a reghack that fixed one of our programs, but other than that we are still screwed. To top it off, our company is a software development company, and our programmers aren't too happy with the world right now :) They and the QA people are having to test all of the last 5 versions of our software suites with various OS's and this patch. Lots of OT to be had :) -d |
.
We deployed it here and it works fine. 1200+ XP desktops. Av. |
Did you deploy it using the exact instructions listed above including the way it was setup in the GPO? |
Strange. I couldn't get it to work and after pulling my hair out I found a bunch of posts online about how it doesn't work either. If you're using a logon script or any soft of third party tool to deploy it (scriptlogic, etc) then it'll work, but the way they set it up in the GPO I can't see how it would. I discarded the VBScript portion of it completely, and just reset the Timezone information in the Current Control Set directly to EST, which isn't a big deal since we only have two servers outside of EST. Pushed my hack of it out to about 1000 workstations Friday. The Servers (~150) are getting it as they go through the reboot cycle this week and next week. |
|
I deployed the XP hotfix through WSUS last week without incident, then had to tackle exchange 2003. Went to SP2 + the DST hotfix, then had to run the exchange calendar update tool. Everything actually went pretty well. Even the windows 2003 update was seamless with no reboot required. I also tested the intelliadmin.com DST fix on Win2K and it seemed to work as well. I was really scared about the Exchange one, but I guess I was lucky this time. |
|
The DST patch also can mess up some International TZs; Mexico and other parts of Latin America used to use US Time zones. With the new DST Patch, this is no longer the case. Command line tidbit for changing the Timezone (without quotes), but using the Exact spelling Windows uses for timezones: control.exe TIMEDATE.CPL,,/Z "Your Time Zone" Example: control.exe TIMEDATE.CPL,,/Z Mountain Daylight Time (Mexico) It usually takes about 5 seconds for this command to actually make the change. We created a script to correct this on over 5,000 machines in Mexico. |
We contemplated all of the options for our Exchange Environment (E2K3 slowly moving to E2K7) and decided that we were going to have the users update their XP boxes and make them fix their own calendars. We tried the TZ fix tools from MS, but they were going to make the problem worse. Hell, we were going to migrate everyone from E2K3 to E2K7 this week because it is "Not Affected", but when you migrate, it doesn't auto-fix the calendars. So the users are on their own. 
|
|
Fortunately our 5000 e2k3 users are all in a single timzone...i'm having pretty good luck with the server based tool. The best method i've found is to use the prebuilt VM they have posted (for VPC or virtual server). about 2/3 done with updating their calendars. Unfortunately a lot of the desktops (thankfully not my problem) are still on xp sp1 and can't use the client tool. |
|
all of our linux servers are fine, and have been for months. If you run this command:
and you get this output:
You are already set for the DST change (the output states that the changes will take place on March 11th and November 4th). If your installation isn't set to notice the new DST times, checkout www.linux-watch.com/news/NS6300294422.html |
|
seeing that the law was changed a few years ago, why'd all the companies wait until the last minute? (at least it sure seems that way) monday is going to blow at work, even more so for the other guys that handle more than one companies' support I only have to deal with one bank, and I think their patches for the Groupwise servers were working ok |
| well first of all no work could be done until after the end of the previous period of DST. In most instances it shouldn't be a big deal, however companies that have older systems are going to have problems as vendors end official support or they have been customized so much that each system requires a custom written patch. |