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.