The Pre-Insertion / Post-Insertion Punch List

There is a set of questions that recur as clients undertake their migrations. Since Exchange is a moving target and we are focused on the calendar data portion of it - we are providing this short punch list with links to make sure users find the most relevant info as quickly as possible.

Setup a service account

• Ensure you have read/write, send-as permissions.
• Check by using the following commands (in DOS at the command prompt) and drill down the path until you can enter into a user’s inbox :
• Subst t: file://backofficestorage
• Dir t:
• Subst t: /d

Turn off handheld device servers

• Otherwise your users are going to get lots of invitations they will not be wanting in the transition.
• BlackBerry server documentation is here.
• Good server documentation is here.

Check the configuration of your user accounts

The issues are:

1. Mail Forwarding (altrecipient)
2. Rules
3. Calendar Message Management: Especially Delegates (aka Proxies in Meeting Maker, Designates in Oracle Calendar Server)
4. Are users running in Cached Exchange Mode?
5. If accounts do not validate - Is there an SMTP address alias@domain.com? Do you have adequate permissions?
6. If you are not sure if you should migrate a calendar account, then MIGRATE the account! After a migration, it’s easy to delete an Exchange mailbox/cancel current meetings. It’s a huge amount of work to insert additional users (it really is as much effort as re-running the insertion).

Mail forwards (alt-recipient)

You don't want mail forwards enabled for the migration. If you have them enabled then users who are forwarded will not be correctly responded for. There are a couple of good Microsoft references on how to determine if an altrecipient is enabled.

• Import or export directory objects using csvde
• There is also a script to determine this.
• And forwarding a meeting request is bad practice. See this article.

Remove/disable RULES both Client-side and Server-side

Again, there is a good reference on how to do this: How to Use the Mdbvu32 Utility to Remove Inbox Rules

Delegates (setup; receives copies and forwards of meeting invitations)

• In the latest version of the Sumatra Event Sink, if delegates receive COPIES they should be taken are of.
• If some are still around, use the Sumatra Utilities with the /a: switch on that mailbox.
• Do not allow the situation where delegates receive ALL invitations, this will leave all invitations unresponded to for that guest
• Listing Which Exchange Users Have or Are Delegates is a very helpful collection of info.

Configure Resource Accounts

• Setup your conference rooms as soon as possible. Keep them out of the GAL (so nobody can book meetings in a "land grab"), or disable the accounts until you’re ready to migrate.

Login/Access during migration

You don’t have to disable login, but you might want to strongly suggest that users remain off the system until all meeting invites have been sent and guest responses processed.

Exchange backup/logging/Cluster Fail-over

• Although the Sumatra UNDO capability in the insertion code will selectively remove all migrated calendar data, we still recommend you run a backup (in production) immediately prior to starting an insertion to ensure the logs have been compacted.
• In your TEST lab, turn on Circular logging if you don’t care about the losing the ability to restore from backups. This keeps the logs from eating all of your free storage.
• In production DO NOT turn on circular logging. If you have to restore, any messages received will be lost.
• Make sure Operations knows when the production/cutover weekend is. Make sure they do not fail-over the cluster during the migration process (we have seen this happen in real migrations).

Oops… I need to add a user marked as DROP

• Talk with Sumatra about this. It CAN be done but there are limitations.

Remove the event sink ASAP after the migration is completed.

• See your migration documentation.

Calendar Conflicts in Cached Exchange Mode in 2K3 sp2

Administrators universally agree that cached exchange mode in Exchange 2003 is a good thing providing added value and reliability to their infrastructure.

Programmers who write applications which interact with the calendaring functions unfortunately, are tearing their hair out and cursing their fates.

The situation:

We've built Rhino, an Exchange (server-side) solution to intercept and process calendar messages. The solution uses a synchronous an Exchange event sink. The event sink understands certain rules (via an XML file) that allow the system admin to :

• Process meeting requests, replies, or both;
• Skip managed resources;
• Process requests as tentative, accept, or decline, and show the meeting as free, busy, or out of office
• Process replies - keep/delete accepts/declines/tentatives or any reply with a reply from the end user.
• All replies are processed to update the owner's tracking tab.
  

We manage the messages at the server side using CDOEX (version 6.5.7638.1) and EXOLEDB (version 6.5.7650.7) embedded within a synchronous event sink. This event sink works as designed when clients are connected to the Exchange server without Cached Mode.

The problem:

The problems that we are seeing is that the sink generates an Outlook Sync Issues "Conflicts" when clients use outlook in 'cached exchange mode'. i.e. clients see message on the meeting ... "You made changes to another copy of this item. This is the most recent version...."
Also when an Outlook meeting owner attempts to update one occurrence of the meeting, and changes the location, or adds an agenda, the meeting owner's calendar doesn't always get updated with the changes that he/she just made (e. g., the agenda gets lost, the location disappears from the subject line annotation in the calendar view, but still exists in the meeting detail view); and agendas are never received by the end user, until the meeting owner updates the same meeting occurrence twice.

Clients most frequently see this conflict message when they update meetings, or change a single occurrence of a recurring meeting.

What is going on here:

This is a bug in the ICS (Incremental Change System) for Exchange 2003 in cached mode.

Steps to reproduce:

1. Create a Synchronous event sink in VB 6 using the event sink wizard from the exchange SDK.
2. Add in code to detect and process calendar messages (see MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_cdo_processing_meeting_request_responses.asp
3. Compile the code, register the event sink on your system mailboxes
4. Create a recurring meeting using Outlook in Cached Exchange mode.
5. Have that “guest” accept the meeting
6. Open an occurrence of the meeting, and change the location, agenda, etc. Send an update, then switch to the inbox.
7. Have the “guest” accept the update.
8. Open the Guest’s response message (in your inbox)
9. Switch to the calendar and open the meeting (you should see a conflict)

We've added the VB source code for main module as a comment to this post. The VB Project is available to those who request it.

Remedies we have tried already:

Microsoft support suggested their Auto Accept Agent that is implemented as an asynchronous event sink, but again you need to install this on every mailbox:
883130 The Auto Accept Agent Deployment and Administration Guide is now available
http://support.microsoft.com/default.aspx?scid=kb;EN-US;883130
903290 You should not register a resource mailbox for Auto Accept Agent in Exchange 2003 when you set up a resource for direct booking in Outlook
http://support.microsoft.com/default.aspx?scid=kb;EN-US;903290

Note: The auto accept agent is also an async OnSave agent.

Non-viable options:

• Don't use cached mode with Outlook 2003 (This isn't an acceptable solution)
• Asynchronous sinks (We tries these and it still generates conflicts, aside from which they need to be registered on each mailbox)
• Direct booking (Really geared towards resource mailboxes)
• Server-side rules could be set up to try to handle this (Again this would have to be implemented on every mailbox where we want this functionality -- more complex administration overhead)

Our solution:

We're implementing an Outlook best-practices client-side COM+ add-in for Outlook 2003 / 2007. Please feel free to contact us if you want to try it out.

Send As... permission and Exchange Hotfixes

For Rhino users and Sumatra Exchange Pump users, and Sumatra Utilities users, Microsoft's various post-sp2 Hotfixes for Exchange 2003 have been causing havoc with the Send As... permissions necessary to put calendar data properly into Exchange.

Good has the best summary we've seen of how to deal with this:

http://www.good.com/faq/17540.html

cdoEndByDate Broken

Usually we like to report things that can get fixed. But as we've discovered, fixes to Collaboration Data Objects (CDO) just are not to be hoped for.

We were attempting to create recurring banners in Outlook using CDO server-side.

As this sample code illustrates, the error comes from CDO directly.


Set oApp = New CDO.Appointment
oApp.Configuration = iConfg
oApp.StartTime = CDate("10/4/2006 10:00:00 AM")
oApp.endtime = CDate("10/4/2006 11:00:00 AM")
oApp.Duration = 1 * 60
oApp.Location = "My Cube"
oApp.Subject = "Test: Create Meeting in VB.NET"
oApp.TextBody = "Hello..."

' Add recurring appointment
Set iRPatters = oApp.RecurrencePatterns
Set iRPatter = iRPatters.Add("Add")
iRPatter.Frequency = CDO.CdoFrequency.cdoWeekly
iRPatter.Interval = 1 ' 1 hour from 10 to 11
iRPatter.DaysOfWeek.Add (3) ' every WED
iRPatter.PatternEndDate = CDate("10/25/2006 11:00:00 AM")
iRPatter.EndType = cdoEndByDate

Our recommendation: create them as non-recurring entities and inform users if they want to make them recurring. Since Outlook does not use CDO to interface with Exchange (ever wonder why Microsoft released CDO in the first place?) that will work.

Migrating from Oracle Calendar Server to Microsoft Exchange while retaining recurrence patterns.

Oracle Calendar to Exchange -- Recurrence Pattern Recreation

When Sumatra reads Oracle Calendar Server data, it readily finds all of the instances of recurring meetings and activities – but the pattern created in OCS / CorporateTime is lost.

To make transition more seamless for the user community when moving to Exchange, Sumatra has developed methods of re-creating equivalent recurrence patterns and implementing these in Exchange.

While most recurrence patterns are simple and map readily, some of the patterns Oracle can create cannot be mapped into Exchange in any simple way – in these instances we insert the appointments or meetings as multiple instances with no recurrence pattern.

The following explains this in more detail.

Daily patterns in Oracle Calendar Server map easily into Outlook recurrence patterns.

Weekly Oracle Calendar Server patterns also map easily. For consistency, some “daily” patterns in OCS are translated into the equivalent “weekly.” That is – a “daily” OCS meeting that happens every 7 days is the same as a “weekly” meeting happening every “Tuesday.”

Monthly on Dates Oracle Calendar Server and Monthly on Dates in Microsoft Outlook are more problematical.

As you can see in the screen shots, OCS allows multiple collections od "by dates" or "by specific weeks."

We map these OCS occurrences if there is ONE of them per month. If there are two with the same title, we cannot translate them into an Outlook / Exchange recurrence pattern because Outlook allows only ONE such instance per month for a recurring meeting.

In cases where OCS has multiples (and our statistics show this is a rarely used condition relative to other recurrence patterns) we leave them as single instances.

Yearly recurrences map from OCS into Outlook / Exchange with no problems.

As always in migrations, there is usually ample time to work out special cases for client requirements.

Oracle Calendar In-Tray capability in Outlook 2003

Russ (in charge of the Exchange Insertion Team) has written a new article on how to mimic Oracle Calendar In-Tray capabilities in Outlook 2003.

Check it out at Outlook Exchange: