Zimbra Insertion: Suppress Resource Responses

So you're migrating all your calendar data into Zimbra and you're not forgetting the all important resources.


BUT you notice that the INBOXes of meeting organizers is full of responses from the resources post-migration.


Not to worry -- you can turn that off with:

zmprov mcr zimbraCalResAutoAcceptDecline FALSE


Just don't forget to turn it on again when you go live.

Many thanks to the folks at Zimbra for cluing me in and to Jennifer who field tested it!

Free-Busy lookups from Oracle Calendar into Zimbra or Outlook

Oracle Calendar users yearning to break free, what do you see that's unusual about this picture of the Oracle Windows Client?

Right! It's the little button that says "Z-Conflicts" just underneath "Remind Me" and "Tentative."

Why have we hacked our way into the OCS client? (Windows only for now, sorry Mac and *nix users.)

Because some of you have been asking for free-busy look ups from OCS into Outlook/Exchange and Zimbra, and this is how we can do it. Your reasons are usually that you must do a phased migration from OCS rather than a "Big Bang" and the problem just seemed so perfectly up our alley.

Right now you click it and it just brings up our internal web page -- but the next step is to click it and have it offer a list of non-OCS users to check free-busy status on. When you select a time it'll drop those into the OCS external email calendar invitation interface so you can more easily customize your invitation.

We're working on the interface between migrations. Stay tuned.

Oh, we have no doubt this will not be supported by Oracle, but hey, you're looking to get out of that suite anyway.

Automatic insertion into Zimbra

Users moving from Oracle Calendar Server or Meeting Maker to Zimbra:

The Sumatra application that takes your intermediate format database and converts it to ICS files can now also automatically post to Zimbra (saving you a crucial step).

The format is the same as you are used to:

zinsert -fo -tf_utc_to_timezone -cs DSN=Zimbra -post http://YOURSERVER/home/[login]/Calendar?fmt=ics -loginpwdb

will auto insert, reading the User ID and Passwords from the Users table of the database.

In the example above you see that user "Puffy Amiumi" gave the error "No TZID for TimeZone" because we had not yet mapped the Japanese OCS Time Zone to Zimbra format.

When Exchange aliases are the same as Meeting Maker aliases

All our best improvements come from users, and this one is no exception.

Current migration uses can use conversion database version 8.7.7.3 or above to achieve these ends.

Scenario:
Let's say “Most” of your Exchange aliases are similar to Meeting Maker Logins, so you built the list of Exchange aliases from the MM user table. Now you have to update accounts that have a different Exchange alias:

New Approach:

1. Add your domain name to the “customer_setup” table
2. Run a query “Q_Build_CustIDs_From_MMUserids” to build the “customer_setup” table from the MM “Users” table
3. Add entries to the “User_Adjusted_Maps” table to “remap” MM Logins to Exchange aliases. Please remember to include both the MM Login and UserID
4. Run the query “Q_Build_CustIDs_AdjustExchangeAliases” to update the customer_setup with the correct exchange aliases
5. Run the query “Q_1_Make_User_Map” to build the mm_exchange_user_map table.
   

We haven't tried this with Oracle Calendar Server conversions yet but the logic should work exactly the same.

Exchange 2007: Running Parallel Insertions

Let's say that you have 5000 or more users, or 2000 users with lots of history (5 or 6 years), and you are migrating into Exchange 2007. You are a likely candidate for running multiple instances of the insertion code. Multiple instances leverages the speed of the 64-bit server processors and the speed of the SAN as you push simultaneous transactions at your CAS server.

If you're running multiple instances follow this procedure:

Step 1 VALIDATE your main conversion database, fix any validation issues and re-validate. You've been taken through this multiple times if you've been in the lab with Sumatra for anything beyond an hour.

Step 2 MAKE COPIES of your validated conversion database and name them something OBVIOUS, like Instance1_YourCompany_28Dec07_DB_v8.7.7.7.mdb, Instance2_..... etc.

Step 3 DISTRIBUTE accordingly to separate client machines (remember, this is Exchange 2007 and you can't run on the 2007 server)

Step 4: EXECUTE SuExchange2007.exe (aka the Sumatra 2007 Insertion Code)

Step 5: SELECT Run Multiple Instance at the "Single Instance" prompt, enter the instance number. You should clear the stats table if you've run multiple instances before. Here's a screen shot:

Background: You'll need a separate database to track the progress of each instance. We call this the "sync database", which you can think of as the traffic cop keeping all the instances running smoothly. It's usually called SyncStats.mdb.

Step 6: Point to SyncStats.mdb in the InstanceDB box.

Step 7: For all instances, select the Lower Limit and the Upper Limit by alpha that you want to run. You want to make these roughly equal. For example, you might select:

A to J (Or you can set the upper alpha limit to "J")
K to R
S to Z (or set the lower alpha limit to "S")

SET UNIQUE Instance Numbers for each of these before executing.

Anything preceeded by numbers (e.g., 3rdFloor Conf Rm) will automatically come at the beginning of the alphabet with A.

Keep track of these so you do not forget letters. This HAS happened in test cases in the field and it became really obvious really fast.

Step 8: Start running all instances

Step 9: Wait. Actually we're not trying to be funny here -- the application is going is to pause before steps 6 and 10. When all instances show the same pop-up box, you can resume all instances. (We've taken you through the reasons for this -- but if you have any questions, please ask.)
Next step: Analyzing your data and doing QA on the insertion.

E2K7 Adding Delegates to Other Users' Accounts

For a migration into Exchange 2003/2007 we recommend you not have set Delegates. Those of you who have left your Delegates on in your lab and migated a few years worth of data have seen why: very full delegate inboxes, and very irate delegates.


The problem still remains: What's the best way to set Delegates AFTER a migration? You could use this as a learning opportunity for your users: let THEM set their own darn delegates, thank you very much.


But sometimes your user community is more demanding and wants (nay, NEEDS) this all done for them.


We have an account in Connecticut (thank you, Vince) who wrote up this account of how to set Delegates for calendars in Exchange 2007 (do not attempt on E2K3). This assumes your Exchange Admin account with adequate permissions to execute (and you know that is its own separate issue) is called "sumatra"

1. Logon to Windows box as yourself.


2. Delete the "sumatra" account if it is in C:\documents and setting. If it is not there then it will be after this first account adjustment. You are good for the 1st run.


3. Locate the Outlook app and "Run as..." and run as the Domain Administrator


4. Setup the user you want to add Delegates to


5. Once done you will be asked to logon, again. This time logon as "sumatra"


6. The account will then be setup in the app.


7. Set your Delegates.


8. When done close Outlook


9. Delete the sumatra account (as mentioned in step 2) and the administrator account.


10. Repeat steps 3-9 until you are done with your account setup.

All bets are off once sp1 hits the street -- we can almost guarantee this process will change.