Daylight Savings Time might be permanent? Your legacy systems might be in trouble.

So Congress voted to make Daylight Savings Time permanent.

 Last time the DST changed Microsoft got caught with its pants down.  Actually they were completely off and their underwear was dirty -- but who needs to remember that?

Well, actually we all do now -- because if you've got a legacy system -- and SOMEBODY keeps reading on our blog about Exchange 2007... you might need to do some legerdemain on your data to keep it working.

OR if you're migrating from a legacy system into Office 365 you are going to be facing problems.

If it's BIG for you -- drop us a line.

We did this before.

Daylight Savings Time and Exchange Hybrid Environments -- Remember to apply CU6

Microsoft released June 2017 Quarterly Exchange Update (for Exchange 2016) on June 27, 2017. This pushes the build number to 15.01.1034.026

It's a MUST update for:

• Exchange Hybrid Environments (for more see a recent Sumatra Blog post on hybrid directory structures), particularly when the alias and SAM account names are different.  
• US customers -- it has the latest DST updates.  
• Sumatra's European customers -- it  fixes an error when the mailbox name contains an umlaut (Jörg, Hans-Günther, Köller, Müller, Dück and MANY more will be happy!)

Download Exchange CU6 for Exchange 2016 here.

The Absurd Side of Daylight Savings Time

Put your personal politics aside for a minute and remember that this is SATIRE. I have raw memories of an expository writing class where half the people in it did not realize that A Modest Proposal was NOT serious!  Actually, it was serious, just not in the direction they thought.  Some of those people probably work for the Federal government now.....

But OBAMA PERFORMS ILLUMINATI DAYLIGHT SAVINGS TIME RITUAL TO CAST WORLD INTO LIBERAL DARKNESS, ONE HOUR EARLIER is just darned funny.

Daylight Savings Time is the bane of the calendar server migration expert.   You need to have excruciatingly detailed knowledge about what is happening on both the source and the target server, and sometimes you just need to deal with bad situations.

Addition: March 9, 2015.  Nacho Punch has an entire series of DST-themed comedy.

Russian Time Zone Changes and Exchange

The title says it all:  Be aware: October 26, 2014 Russian Time Zone Changes and Exchange

Daylight savings time changes -- the gift that kept on giving.  We only tell stories of the great 2007 US DST shift with fermented beverages in our hands.

Buona fortuna aux nos amis les russes !

DST: The Gift that Keeps on Giving

The new North American Daylight Savings Time rules are a lot like the message in Repo Man: the life of migrating calendar servers is aways intense.

Here's the thing to keep in mind: If you're going into Exchange 2003 -- make sure you've applied patches for the new DST shifts.

EHLO has this good posting on the subject: Exchange 2003 and DST fix.

Exchange 2007 automatically has the DST shift dealt with.

Now there are some vendors out there who tell you that as long as you're in the same time zone you're covered, you don't need to upgrade Meeting Maker or Oracle Calendar Server. That's true -- until you migrate.

We can handle re-basing the events in either of these to make them work if necessary. Please just be on the lookout in your test lab for meetings and appointments off an hour in the "DST Delta" in March and November.

As always, it is much easier to deal with these if we find them early.

Update to Sumatra Utilities - current version 2.3.25

Kudos to Shabana at Marfic who found a bug in holiday insertion with the Sumatra Utilities.

We had to rev the code so that holidays would insert correctly with the new CDO that Microsoft issued to cause fix the DST fiasco.

If you're trying to insert Holidays please use version 2.3.25.

Reports of problems with solution to KB 932511

Chris Quinn, one of our brethren calendar and scheduling wonks, has reported an additional problem with the solution to KB article 932511: Exception meeting requests are deleted from the calendar in Outlook 2003 when recipients use a CDO 1.21 application to accept the master meeting request


This of course comes up because of the DST issue in North America, in his case he had an exception to a meeting that had been scheduled to another resource. The fix on 932511 and the Rebaser put the exception back on the ORIGINAL resource.

We'll keep you updated on if there is a fix to the fix to the fix (we think the recursion only goes that far, but after three we just lose interest and move on to other projects).

Chris also reports that:

Because we forced all the updates we also found out about another
problem. We found that OWA views can differ significantly from the Outlook
views. So we found another article that was quite interesting.
I thought you'd get a kick out of it. Now we can all POOF our calendars…
http://blogs.msdn.com/stephen_griffin/archive/2007/02/21/poof-your-calender-really.aspx

NB: To all of your looking to migrate Proxies and Designates from legacy calendar servers to Delegates in Exchange -- we need to use CDO 1.21 to accomplish this and the acknowledged memory leaks (see KnowledgeBase Article 891509 A memory leak condition occurs when you create a CDO program or a MAPI32 program to log on or log off many mailboxes in Exchange Server 2003 SP1) are one reason we treat this very carefully. See also KBs 901014 and 913643.

Using the Sumatra Utilities to archive appointments

In our continuing effort to make sure you don't think of the Utilities as something just to use to fix the looming Exchange DST crisis, we have a new feature to blog about:

archiving

Aside: you multinational companies shouldn't think it's almost over! I've gotten at least two inquiries from Europeans who are wondering about using the Utilities when the European Union reviews DST for its member nations. And "just move to Exchange 2007" is not the clear answer for everybody.

So why use the Utilities to archive? You could use automatic archiving to a PST file -- which will reduce the size of your local data and speed things. BUT if you want easy access to this data and still want to speed your calendar display, you can use the utilities to move all appointments before a certain date to a specified archive folder.

This gives you the best of both worlds: Better speed AND easy access (if you need it).

So to move all of user “riuliano”'s one-time (non-recurring) appointments before 8/2/2006 to a folder called “My Old Cal Items” use this command:

Su /u:riuliano /dt:8/2/2006 /mc /fn:"my old cal items"

If you do not have your aliases as SMTP addresses, use this syntax:

Su /fn:”my old cal items” /mc /dt /smtp /dn:lab.sumatra.com /u:russ_iuliano@lab.sumatra.com

to move appointments for user russ_iuliano@lab.sumatra.com (identified by SMTP address, /smtp) one-time (non-recurring) appointments before yesterday to a folder called “my old cal items”.

Not sending Updates? Check for meeting corruption with the /x flag.

It's easy to understand why you might find the Update storm a hassle. And you've probably made sure your Microsoft reps have heard this.

So the latest Microsoft Time Zone Update tool lets you suppress Updates.

But, after you've read the warnings about what could happen if you suppress Updates in KB 933146, you should also check out some other warnings about this being contraindicated behavior in the following other Microsoft articles:

• KB 899704: Description of common scenarios in which Calendar information may be removed from the Calendar or may be inaccurate (search for "Update")
• Outlook Meeting Requests: Essential Do's and Don'ts: "Send Updates" is the second point here.

As always -- our credo is "test the snot out of software in your lab before you deploy to your production environment." If you have no problems in your lab then odds are in your favor when you move to production.

Quick Test for Corrupt Meetings

In the course of various post-migration follow ups we've heard of corrupt / damaged meetings (and improper updates is only one of the possible vectors of infection). So the Utilities have a /x flag to check:

su /u:exec_cr /x

Will look for mis-matches (i.e., a meeting in the OWNER's calendar that is in a different time / place from the entry in the calendar for the Executive Conference Room (exec_cr).

This particular flag got most of its use early on in smaller Exchange installations, so it currently might not scale to large organizations very well (but neither did some of the other flags until a few weeks ago).

Migrating Exchange Calendar to Google?

Those folks at Google could not have picked a better time to bundle their email, calendaring, spreadsheets, and word processing into the Google Apps-Premier Edition package. For one thing I haven't heard the word "Rebaser" used in conjunction with any of their calendaring apps ever. On the other hand, last time I looked at Google their resource manager strategy was non-existent.

So if any of you folks out there are interested in migrating your Exchange calendar data into Google and keeping all the info you need (like recurrence patterns, guest lists, responses, exceptions, all the stuff that makes calendars useful) drop us a line.

And please keep in mind - we are not talking about moving one user account at a time -- our solutions move entire servers of calendar data at once with no user intervention.

We clearly know our way around Exchange calendaring.

The /debug flag

Along with the revised /SMTP flag we added a /DEBUG flag to version 2.3.20.

Actually we re-added /debug since it was in previous versions. Before this whole Exchange DST fiasco from Microsoft the Utilities did not run into a lot of widely different organizations so we didn't really need it.

Invoking /debug adds additional information to the error.log file.

If your SMTP addresses do not include Alias@domainname you need the /SMTP flag

In the hundreds of calendar server migrations we've done we've run into just about everything at least once. When we run into them twice we put it into the software so the third time is no problem.

Such it the case with the new, improved /SMTP flag.

You can thank Femi and Ron from T Rowe Price for giving us the concrete example of why we should make it more general. Originally we only dealt with SMTP addresses rather than aliases for automatic meeting archiving. (Keep in mind, the Utilities are one of those Swiss pocket knife tools that does more than DST.)

Why do you want this? If your SMTP addresses do NOT include the address Alias@yourdomain i.e., Joebob.Exchangeadmin@yourdomain.com instead of joebob2321 which is the Alias / Logon ID / directory name which your data is stored under in backofficestorage.

So the NEW version of the Utilities allows you to profile and act on IDs as SMTP addresses using the following syntax:

su /u:joebobexchangeadmin@yourdomain.com /DST /SMTP

You can also use this syntax with SMTP addresses in an input file.

Main symptom of the need for this syntax:

• You are able to "drill down" in backofficestorage using the subst command and see calendar items
• BUT you are still getting -13 errors

February 25, 2006: We're adding this capability to the /a and /db flags (which we have done and are testing now). Owing to some very bad behavior by a major company founded by H Ross Perot we're deciding whether to release this to the public or not.

Permissions - Your most likely error

Let's say you have the Sumatra Utilities installed and are getting an error with one of your users (typically -13 User Does not Exist on this server). And your error.log file looks something like this:

Debug: Commandline: /u:riuliano /DST:ALLDATA /DN:lab.sumatra.local riuliano WAS NOT Validated (User Does not Exist on this server) url:file://./backofficestorage/lab.sumatra.local/MBX/riuliano/-13NOT Validated:

Easiest way to make absolutely sure of permissions is to walk the tree using the account you're using to get to this:

• Shell into DOS
• Use the command subst o: \\.\backofficestorage
• You should be able to drill down to the mailbox you want to profile (if you cannot you either do not have permissions and need to fix it, or the user is not on that Back End server)
• See the following screen shot example
  

NOTE: please remember to remove the temporary drive when you are done (and BEFORE you close the DOS window) by entering

• subst /d o:

Why do the Utilities require .NET Framework 2.0?

We have just gotten our second contact from a user who was wondering "Why are the Sumatra Utilities built with .NET 2.0?"

A fair question - a few of us here at Sumatra have been frustrated by the additional overhead and complexity that .NET 2.0 entails and yearn for the old version of the Sumatra Utilities which did not require 2.0 (and can be downloaded here). Remember it's a year old, so there is NO /DST switch but the /a for Accepting invitations and the /db for double-booking are there (but in the old version /db only looks 15 days ahead).

So why do we require it?

Security.

As the article New and Improved Security in the .NET Framework 2.0 shows, .NET 2.0 has a much stronger security model, and that was a very hard argument to refute.

/DST:alldata -- you can get even MORE info from Exchange

Suppose totals are not enough and you really need to be able to get a log of ALL meetings and appointments that are in the DST interval. Is there a way to do that in the Sumatra Utilities?

Absolutely, and it does not even require you download a new version.

The command

su /u:zyg /DST:alldata

will put into outfile.txt all of the meeting and appointment titles in the DST interval for user "zyg", with the Start Times, End Times, what it thinks the Rebased Time Zone will be, the organizer, pretty much all the information you want to have if you need to have a safety net for your critical schedule users.

The output file is very easy to parse:

User:zyg
Alias MtgStartTime(UTC) MtgEndTime(UTC) Timezone Rebased TZ? Mtg Name Organizer Meeting Type
zyg 3/10/2007 5:00:00 PM 3/11/2007 1:00:00 PM (GMT-05:00) Eastern Time (US & Canada) 10 Appointment crossing new DST boundary 5:00 PM Sat to 11:00 AM Sun zyg@sumatra.local Appointment
zyg 3/12/2007 10:00:00 AM 3/12/2007 10:30:00 AM (GMT-05:00) Eastern Time (US & Canada) Test recurring - zyg has client zyg@sumatra.local Recurring
zyg 3/12/2007 10:00:00 AM 3/12/2007 10:30:00 AM (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London Recurring Outlook meeting in GMT passing through Delta jam@sumatra.local Recurring
zyg 3/12/2007 10:00:00 AM 3/12/2007 10:30:00 AM GMT -0500 (Standard) / GMT -0400 (Daylight) OWA Recurring meeting - GMT jam@sumatra.local Recurring
zyg 3/12/2007 1:00:00 PM 3/12/2007 1:30:00 PM (GMT-05:00) Eastern Time (US & Canada) Every Monday 10:00 AM zyg@sumatra.local Recurring (Exception)
zyg 3/12/2007 5:30:00 PM 3/12/2007 6:00:00 PM (GMT-05:00) Eastern Time (US & Canada) 10 Tentative zyg@sumatra.local

The most successful strategy we've heard of is to do a "before Rebaser" and "after Rebaser" snapshot of the data most crucial to you.

We apologize for constantly using the examples of "zyg" and "russ", but when we used "ben" and "jerry" we used to get stern letters.

"Correct Accept" for the Coming DST Update Storm: Call for Betas

In one of those crazy "Aha!" moments that strike Russ and Zyg every so often (in this case while Russ was on a train back from NYC on the cellphone with Zyg snowed in in Boston discussing the dreaded DST Update Storm) we think we have an implementable solution based on Rhino that holds the promise of:

• Responding correctly to Updates based on what a guest had responded to begin with (so if the guest DECLINED originally or hasn't responded yet it won't put it back in her calendar)
• Be easy to install and configure (I.e., you won't see large parts of the Rhino configuration interface for those of you who find it daunting)
• Be easy to remove once you're done
• Touch ONLY "Update:"s (With mainstream Rhino installed you will get automatic acceptances for ALL invitations while Rhino is active)
• Given all the above we think it'll work well for Conference Rooms so long as you turn off your various resource managers, but that you should test in your lab.
• English-language Exchange only (unless someone comes up with a good reason for adding another language)

If there's interest out there in taking this for a spin after we're done with it and put it through some test cycles drop an email to "zyg AT sumatra DOT com"

Keep in mind -- we've been doing this a while but we've never seen perfect code (and we're still amazed at some of the cases you folks can come up with). So we're talking test labs and safe software habits (anybody putting this in production before talking with us is not getting support).

SU /a Flag -- What order does it use in accepting pending calendar items?

The Sumatra Utilities /a flag does the oldest email invitation first and proceeds to the newest. Think of it as First-Come First-Served.

This helps it to avoid accepting something that is out of date and replaced by a newer item.

It doesn't look at the time of the actual event -- it looks at the time of the event invitation.

Troubleshooting tips for users and FAQ for the Microsoft Calendar DST update tool

Gentle Reader,

Miss Meeting Manners received the following FAQ from our absolutely most knowledgeable and capable client, Nancy from Qualcomm. A soul intrepid beyond imagining she has undertaken this weekend to update all of her 10,000+ Exchange users with the Microsoft DST patches. She sent us this FAQ and invited us to share it with others in the same situation as she is. If you use it please credit her, she deserves it.


Why am I getting spammed with calendar items? Can I delete them all?
Since Outlook uses email to manage calendar updates, the only way to update a meeting and fix the time is to send out the change to all the invitees. Unfortunately the tool does not differentiate between Accepts and Declines so even if you declined the meeting before you will once again have the opportunity to decline the update again. Updates are ONLY going out for meetings that fall between 3/11 and 3/31. It is NOT for every single meeting on your calendar.

What order should a user accept the meetings in?
Accept them in the same order that you would normally. Generally we recommend from oldest to newest, deleting the items that show up as “Out of Date”. Since the Calendar update tool will only be sending 1 update out for each meeting – you should not run into any issues with conflicting updates to the same meeting

My meetings are showing up in a different time zone!
This may happen if the tool has incorrectly determined what time zone your calendar should be in. Contact your Exchange Administrator with the name of the user, what time zone their meetings SHOULD be in – and they can do a one off adjustment if necessary. If the user does not want to wait for a ticket to be escalated – the Help Desk should be able to walk them through running the Outlook Time zone tool – more info located here : http://support.microsoft.com/kb/931667/en-us

Some of my meetings did not get updated- what do I do now?
While we do our best to identify every affected meeting there may be instances where a meeting is missed. Have the user wait until after their Windows machine is patched point – then all they will need to do to fix the meeting is send out an update, moving the meeting to the correct time if necessary. The update will put the meeting back onto their calendar at the corrected time.

Some of my meetings that I created over the weekend were moved back an hour and they shouldn’t have been!
The tool is unable to differentiate between meetings that have the right DST stamp and the wrong DST stamp. We are trying to minimize the number of “good” meetings that get moved by the tool by running it over the weekend and warning people not to create new meetings until Monday. If a user finds a good meeting was moved – please help them send out an update and move it back to the corrected time.

How do I know my meetings are OK?
Put the time of the meeting into the subject. This gives your invitees a very easy way to determine what time the meeting is supposed to be at – even if there are DST display problems.

Now that my meetings have been “fixed” - there is a double booking with the conference room – what do I do now?
We will be running reports before and after the tool is run to identify any double booking problems that may be caused and will assist users to resolve them on a case by case basis in the week after, well before the actual DST change.

Managing your Coming Calendar DST Update Storm: Using Rhino to Auto-Accept

If you are not worried about Meeting Updates for the coming DST change in Exchange, please skip to some other blog.


You can use the Sumatra Utilities /a flag to accept updates (though we'd recommend this mainly for conference rooms and resources).


The Rhino Event Sink can automatically accept for all users on your back end servers. As an event sink it operates as the meeting updates arrive server-side on the user's inbox. This means updates can be accepted or tentatively accepted with NO USER INTERVENTION.

It differs from the Microsoft Auto-Accept Agent in that the AAA is asynchronous and must be registered on each mailbox. Rhino is a synchronous event sink and needs to be registered only once on each back-end server. Rhino also gracefully handles the situation where users have Delegates to respond to calendar invitations.







You can use Rhino with some caveats:

1. Rhino can Accept or Tentatively Accept -- but it does not recreate the original response if it were a Decline. We do not have this restriction during a calendar server migration but we have complete control over that situation and we got the same advance notice you all did of the Microsoft DST Update method.


2. If you are running Cached Exchange Mode do not enable "Replies" processing, that will result in users getting conflict messages due to an Incremental Change System (ICS) issue in Exchange 2003 sp2


3. You can limit Rhino processing to a defined Group.
4. Exchange 2003 only (Sorry Exchange 2000 users but the Sumatra Utilities will happily work in that environment).

DST Updating in Exchange: What the Heck Happened to my Managed Resources?

So let's say you've successfully modified the Time Zones for your Exchange Server, Outlook clients, and run the Time Zone Update Utility.

Your users haven't spontaneously burst into flame, but they are really curious what's happened to the conference rooms.

Accepting invitations for resources

First off: If you needed to turn off your Auto-Accept agent -- or resource management software, and are not running with an event sink that automatically accepts for you, you may have some meeting invitations in your resource Inboxes. Microsoft AAA you should be OK with as long as you set the Depth to "3" as per Microsoft's instructions -- where we've seen issues it's been with the Third-Party Resource Managers (Who shall remain diplomatically nameless).

The Sumatra Utilities can automatically accept all of these.

Use the following syntax:

su /a /u:conf_room

to accept ALL of the invitations in a given Resource mailbox.

Note you can also use the /in:file.txt command to deal with a group (one line per resource alias).

After doing this of course, it is very reasonable to assume that you may have double-bookings.

Determining Double-Booking

You could open each resource and scan the calendars one day at a time, but enterprise calendaring software is supposed to make your life easier not harder.

To produce an output file highlighting double bookings, enter the following:

su.exe /u:conf_room /DB /ND:45

NOTE – for double bookings, the MAX DAYS (ND) is 45 days from today (you cannot change the start date).

Also this will take the /in:filename.txt parameter.

What if the resource is Triple (or more!) booked?

How much functionality do you want in free utilities? Seriously, we handle that -- but it will do all the cross-pairs of double-booking, i.e., if you have triple--booked meetings "1", "2" and "3" it reports in the outfile.txt report that "1" and "2" conflict, "1" and "3" conflict, "2" and "3" conflict .... you get the idea.

But the good thing is that you've got it in one local place from a relatively speedy method.

An example of part of the output file follows for a quadruple-booked case in room "cr222":

--------------------------------------------------------------------------------
Timer: Start=2/5/2007 5:40:30 AM (ver v2.3.18)
--------------------------------------------------------------------------------

User:cr222Resource Mtg Organizer Mtg Name MtgStart MtgEnd IsDblBooked Meeting Type

Validated cr222
cr222 cr222@sumatra.local 4 2/5/2007 9:30:00 AM 2/5/2007 3:00:00 PM Double Booked with 3 Appointment
cr222 cr222@sumatra.local 3 2/5/2007 10:30:00 AM 2/5/2007 2:00:00 PM Double Booked with 4 Appointment
cr222 cr222@sumatra.local 4 2/5/2007 9:30:00 AM 2/5/2007 3:00:00 PM Double Booked with 2 Appointment
cr222 cr222@sumatra.local 2 2/5/2007 11:30:00 AM 2/5/2007 1:00:00 PM Double Booked with 4 Appointment
cr222 cr222@sumatra.local 3 2/5/2007 10:30:00 AM 2/5/2007 2:00:00 PM Double Booked with 2 Appointment
cr222 cr222@sumatra.local 2 2/5/2007 11:30:00 AM 2/5/2007 1:00:00 PM Double Booked with 3 Appointment
cr222 cr222@sumatra.local 4 2/5/2007 9:30:00 AM 2/5/2007 3:00:00 PM Double Booked with 1 Appointment
cr222 cr222@sumatra.local 1 2/5/2007 12:00:00 PM 2/5/2007 12:30:00 PM Double Booked with 4 Appointment