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.