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).

Options for Oracle Calendar to Exchange Migration

There are three good options for administrators looking to solve the problem of moving Oracle Calendars to Exchange. We are restricting this to methods that can be accomplished mainly server-side.

1. Use Oracle Connector for Outlook, save the data to a PST and then Exmerge into Exchange. This is simple, inexpensive, and off-the-shelf, but OCFO is slow (excuse me, performance impaired) and this method does not preserve state information (i.e., guest lists and responses)
2. Middle path: Oracle Calendar tools allow server-side export of calendar information (unicpoutu.exe). It is a fairly straight-forward format to read and with some programming can readily be inserted into Exchange for the appropriate user (Sumatra has tools which do this at about 600 calendar objects per minute). This does not preserve recurrence patterns, but can preserve guest lists. Guest responses are not preserved with this method.
3. Optimum fidelity: This also requires exporting using the existing Oracle Calendar tools. What it further involves is some proprietary technology which goes through the calendars and re-creates the recurrence patterns of meetings and appointments. This gets done in Sumatra's labs and then is turned into a database that can be inserted into Exchange with our tools. This method is more involved, but it maps all former OCS users tinto Exchange users and preserves all guest responses.

Big Bang vs. Phased Migrations:

Need for an OCS-Exchange Free Busy Connector?

Most calendar migrations we see have been "Big Bang" (i.e., all users at once -- which makes it really easy to preserve all the guest lists and responses). Since December 2006, we've had several inquiries from users about connectors for Exchange calendaring and OCS, specifically for Free Busy queries. We put some brainpower on this and think we have a solution. Come back in a bit for more info.

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

DST Updating in Exchange - How Big is Your Coming Email Update Storm?

The Microsoft methods for updating Time Zones for the coming DST shift will require that meetings in the relevant time delta be re-proposed.

It does not take a lot of head scratching to realize that this will potentially result in a lot of email traffic on your servers. It's also reminiscent of how the dentist tells you an X-ray only gives you the same amount of radiation you'd get during a day on the beach (conveniently ignoring the fact that she's giving you the same dose in a few milliseconds instead of eight hours).

So your first question is probably: How much traffic can I expect to have?

The Sumatra Utilities (available for free) can give you the answer.

At the command prompt run:

su /u:jsmith /DST

To get a count of all "jsmith"'s meetings and appointments in the relevant region.

The output looks like this:

Alias Num Appts Num Recur Master Num Recur Instances Num Recur Exceptions Total Items Total Cross Check
jsmith 12 2 19 1 34 34

The final number is the total of all affected calendar entries (meetings and appointments) in the area.

If you choose to do only recurring meetings, look at the third number form the left: Number of Recurring instances. Each of those will require two emails: one coming IN to that guest and one going OUT from that guest as a response.

The totals of these for all your users is a close approximation of the total amount of email traffic you can expect. Why is it not exact? Two reasons:

1. If guests have DECLINED the meetings previously then they're not on the calendar so don't count in the totals but they will receive updates
2. Users who have been invited but have not yet responded may not have this calendar object on their calendars yet.

A quick look at the output file will show you it's tab-delimited so easy to load into a spreadsheet for analysis.

This will work on resource accounts as well.

Our next topics: How to use Rhino Event Sink to automatically accept all updates and how to use the Utilities to deal with managed resources and discover double-bookings without opening all your resource calendars.