Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DST 2007 - My Experience 7

Status
Not open for further replies.

hunterdw

Technical User
Oct 25, 2002
345
US
I'm no expert. Please don't assume that.

This is just my ramblings that hopefully helps you in the process.

The great part about this forum is that we all have different experiences and I'm sure many of you will have better information to add to help the "next guy" who may just now be starting.

--

These last two weeks I've been preparing for DST 2007 on my campus - 110 acres with both Windows 2000 and Windows XP workstations spread out in the deepest and darkest recesses (under tables, behind walls, in desk drawers even).

Reading the info at (this will redirect now) was helpful, but changed every day, and I didn't seem to find the silver bullet "how to" guide that I was looking for.

Here's how I updated our workstations. Your mileage may vary. And, for what it's worth, I'm on EST -0500 timezone.

1) I updated our important servers - Domain Controllers (3), Exchange 2003 Enterprise OS (1), and my WSUS Server (1) which I also used as the "client" updating the exchange info store. I will update the other servers over the next few days, but they weren't part of the initial "push" here.

2) For Windows XP, I installed both KB928388 and KB931836 via WSUS. Why both? Well, until Tuesday 2/13, KB928388 was the most current "fix", but on "patch tuesday", Microsoft released the KB931836 rollup that superceded the prior. I was unaffected by the "changed" in KB931836, but chose to run it anyway.

3) For Windows 2000, I used this KB article and deployed a GPO to an OU I created that contained all my Windows 2000 workstations. It's a computer logon script, so all workstations needed to reboot. Using the sysinternals "psshutdown" tool, and an export of all my 2000 computers from AD, I created a batch file "psshutdown -f -r @listof2000computers.txt" that rebooted all the 200 workstations. This GPO ran the script as expected when they handshaked with AD. We do not have an extended support contract and thus did not have the fancy schmancy $4000 automated update for Windows 2000.

4) Recognize, not everything happened as expected. Some machines were off. Some machines were hosed. So, over the next few days, there will be "one offs" that need addressed.

5) We're on Exchange 2003 Enterprise SP1. I did NOT upgrade to SP2 at this time, so KB926666 was not helpful for me. I'm new to this organization and have not tested our exchange recovery readiness, and did not want to apply a SP2 until I was confident in my backups. So, instead, I ran the Exchange 2003 SP1 tool at KB931978.
6) Next, I ran the Exchange Time Zone Edit Tool - KB930879. KB930879 says you need a "client" to connect to exchange to actually update the calendar entries. I used my WSUS server as my "client". I installed the required software - .NET framework 2.0, Outlook 2003, The Outlook TZ Tool (KB931667), and the OS TZ Update (KB931836). The Exchange TZ Edit tool has two executables MSEXTMZ and MSEXTMZCFG.exe. I used the latter because it was more "wizard" like and walked me through exatly what I needed. the interface is a little clunky, and if you don't know what your "ServerDN" is, it's a convoluted string that looks like this: /o=First Organization/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=SERVERNAME - or something like that. That's what mine looked like but of course you may have different groups, naming, etc. Using KB930879 as your guide, answer the questions in the "wizard" correctly and it will set all appropriate .INI files and create .BAT files for you that will fix your issue.

7) My INI looked like this

[Configuration]
CommandLine = C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.EXE /q /onlyrecurring
ServerDN = /o=First Organization/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=SERVERNAME
ErrorFile = Errors.txt
LogFile = msextmz.log
OutputFile = Output.txt
InputFile = C:\msextmz\SERVERNAME\Mailboxes_1.txt
ReadCalendarTimezones = 1
PostMailboxDelay = 0
PerMailboxTimeLimit = 15
PRFFile = C:\msextmz\daylight.prf
OutlookCommand = D:\Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE /noextensions
OutlookKey = Software\Microsoft\Office\11.0\Outlook
ProfileCreationTimeLimit = 15

8) My BAT file looked like this

C:\msextmz\MsExTmz.exe "C:\msextmz\SERVERNAME\MSExTmz_1.ini"

9) Doubleclick the BAT and watch it work.

10) I chose to only modify recurring appointments. We let the end users handle one-time bookings. Of my Calendars, the "wizard" said that only 144 of them required any maintenance and created the appropriate "input" file with those 144 mailboxes. The "client" machine was an older server - 2 x P3 1Ghz with 2 Gigs of Ram. The Exchange server is 2 x Xeon 2.8Ghz with 2 Gigs of Ram. My entire mailstore is like 32Gigs and is stored on a Xiotech SAN. I'm not a huge enterprise by any means. It took about an hour to run. It created log files of the overall process, and then for each calendar user it created a log file letting me know what was changed.

11) It re-sent any appointments that were recurring from the organizer. The recipient needs to re-accept them. Be ready to address this question when your users ask "why am I getting old appointments?" or "Why did I send that? I already did!"

12) Before the process, we communicated with our user community something like this:

Time Zone Fix: We have prepared a plan to correct the Time Zone entries on both your computer and our servers. As reported yesterday, this correction is necessary because of the new Daylight Saving Time (DST) rules going into effect this year causing an "extended DST" period of 3 weeks in March and 1 week in November. We will be running automated fixes starting Sunday evening and ending Tuesday. Wednesday we will be visiting each machine that was not fixed automatically in order to correct the Time Zones. Wednesday evening, starting at 6pm we will begin updating our mail server and automatically fixing appointments on your Outlook Calendar using tools provided by our email vendor. Please be aware that email, both via Outlook and Outlook Web Access, could be unavailable for most of the evening.

To prepare for manual intervention, please take time to print off your Outlook Calendar for March, April, October and November before 5pm on Wednesday February 14th. Thursday morning, after fixes are ran overnight, please compare your printed calendar to your electronic calendar within Outlook. Recurring appointments during the "extended DST" period in March should be corrected automatically. The highest probability for manual intervention will be single appointments during this "extended DST" time. If you see any meetings during this "extended DST" period that were not corrected, or adjusted incorrectly because of the automated fix, you will need to rebook those appointments as there is not an automated fix available.

13) And after the process, we communicated with our community something like this:

Daylight Savings Time Update: As you recall, we've been busy working on the Daylight Saving Time fixes on your workstations and laptops this week. The final updates to the mail server were completed late last night. Please take time this morning to review the Calendars you printed out for March/April and October/November and compare those with the your Outlook view. Pay particular attention to the appointments during the "extended" Daylight Saving Time period (March 11 through April 1 & again from October 28 through November 4). For recurring appointments, the times were adjusted and the meetings were re-sent to recipients. As a result, you may notice "new" requests in your Inbox for meetings that you have already accepted. You will need to accept them again. This behavior was planned in order to ensure that meeting times are consistent. Single appointments will need to be reviewed and corrected manually on a case by case basis. If you have any questions, please contact the IT Help desk.

--

That's it. Hopefully something helps you. I'm sure there are many glaring details I left out, and I'm sure many of you had a much better process. I'm done, but there are others who are just starting. Feel free to share with them.

--DW
 
I have been testing with the TZMOVE tool and having mixed results. Some recurring appts get changed during the Delta period and some do not. Have you had good success with the TZMOVE tool during your actual deployment?

Thanks.
 
Thanks for the info. I'm sure many people will find it handy. A star for you.

ghud - are the non changed appts for people in non DST areas?

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP
Want to know how email works? Read for yourself -
 
Hi ghud--

Like you, yes, I had a few (less than 5 that were brought to my attention) recurring appts. that were not changed using the EXCHANGE tzmove tool.

It was weird. Not all, just some. As Pat asked, I would be curious if those people were in a non DST area. All of our people are in a single geographic area/single timezone so that wasn't an issue with us.

I chose to manage by exception and just deal with it.

--DW
 
58sniper- All of our calendar entries are EST. I have a test server room where I have an Exchange Server 2003 SP1 and a W2K workstation. I have applied all patches and used the TZedit tool on the W2K wokstation. When I run the TZMOVE tool on the workstation against a server based mailbox some recurring entries don't get adjusted while others are moved back by one hour (about 50/50). The ones that get moved back by one hour would be very confusing to the users and I'm not sure if they will get adjusted during the "delta" period when the clocks actually move forward one hour (I am going to test this today). Does the server wrapper do a better job than running TZMOVE on a workstation? Thanks for your help with this.
 
This article was a great read. Thanks for posting it, it got rid of most of my pre-flight jitters.

I absolutely could not get the MSEXTMZ and MSEXTMZCFG.exe tools to run. I tried both, I tried every single server name, serverDN string, Ip address, everything. Not a single one worked, and it was getting to be 8pm so I figured everyone could do their own and I went home.

I dont want this thing to beat me, I'd like to know what serverDN I have to put in there, but every time I tried it said "Please select the valid server." The worst part is that there isnt a way to select it, just a field to put in the ServerDN name...
 
Just did an interesting experiment this morning with regards to DST and Exchange. We have a redundant server room located at an alternate location in our city. Last week I had applied the OS time patches to the servers in the redundant server room (DC on Server 2003 standard and Exchange server 2003 SP1 on Server 2003 standard). I also applied the CDO update for Exchange server 2003 SP1. This morning I went to an XP workstation and applied the time update to it. I then tested (4) different scenarios:



1. Looked at a test user’s calendar with server and workstation clocks set to 2/21/07 10:15 AM EST.

2. Adjusted the clocks to 3/11/07 1:50 AM EST and watched all three roll over to 2:00 AM and then quickly auto adjust to 3:00 AM.

3. Adjusted the clocks to 3/21/07 10:30AM EST (during period know as EDST).

4. Adjusted the clocks to 4/21/07 11:13 AM (during period known as DST).


In all (4) scenarios the test user’s calendar appts never shifted. All appts stayed the same even when viewing via OWA. None of the appts fell back or moved forward. I then installed the TZMOVE tool and started to run it against the test user’s mailbox. It told me that it found (20) appts that needed re-basing (but I just cancelled out at that point thinking it would just screw up his calendar as in other tests that I had done). I did not take time to look at the EDST period during November but thought that I would get the same results as #3 above.



Does anyone see any weakness in the test above. I know that we are an EST organization only and this may have something to do with it. I don’t recall Microsoft making any mention that the re-basing tool would NOT need to be run if you were a single time zone organization.

 
Just came across this post by chance - obviously this will have the most impact on users in the states, but for users in europe, will there be any ill effects if the updates aren't applied to our PC's? We generally keep our PC's patched up, but just wondering if we need to start doing some testing also.

Sorry if it sounds like a silly question !!

Irish Poetry - Karen O'Connor
Get your Irish Poetry Published
Garten und Landschaftsbau
 
I am trying to run the tool now. I watched this video concerning it to help me through it:
it is a pretty good video, but when i get to the step where it asks for the outlook location, my version of the Exchange Timezone update tool does not have a place to put it in. When i run the batch, outlook does no open. has anyone else experienced this or know of a fix? i tried to place the path from the original poster's ini, but it did not change my issue. Here is my INI:
[Configuration]
CommandLine = C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.EXE /q
ServerDN = /o=EOC/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EOCMAIL
ErrorFile = Errors.txt
LogFile = msextmz.log
InputFile = C:\MsExTmz\eocmail\Mailboxes_1.txt
ReadCalendarTimezones = 1
Profile = Outlook
PerMailboxTimeLimit = 15
PostMailboxDelay = 0
LogDirectory = C:\MsExTmz\eocmail
OutlookCommand = C:\Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE /noextensions
OutlookKey = Softare\Microsoft\Office\11.0\Outlook

here is the error i get when i run the batch file
HrTestMailboxAccess:Unable Open mailbox - 0x8004011D.
 
Hmm. Do you have Outlook installed? Stupid question, I know. Can you open it directly from the Start Menu?

What version of Exchange?

What is the "client" on which you are running the tool?

Under what username?

the error code you provided appears to be one that states you don't have particular access to that mailbox.

Are you sure you set permissions properly for the mailstore?
 
Outlook is installed with a profile connected to the administrator account. I am running Exchange 2003 sp2. the client machine is a brand new computer, logged in as administrator with outlook connected to administrator's exchange mailbox. I believe i get the error that i am denied access because outlook is not opening, the program thinks i am denied access but it has no means of getting access to it.
 
The "administrator" account doesn't necessarily have all the correct permissions to the exchange mailbox store.

did you read the document to double check the "send as" permissions?
 
ha you were correct about the permission thing.. i did give my self permission, but it was also denied to that user. so i just logged in as another account gave it permissions and then ran it. sorry for the confusion!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top