Microsoft Exchange to Office 365 Calendar Migration Preserving Meetings as Meetings

Microsoft does not offer full-state calendar migrations from Exchange to Office 365.

Your meetings will all become appointments.  It's like printing your calendars from one Exchange system into office 365.

If you're a small site this is no big deal and easily managed.

If you're an enterprise where people live in meetings and conference room and resource allocation is crucial this can be a huge hassle which can delay your migration to the cloud.

If you use our technology your meetings will stay meetings. Problem solved.

And this shows synchronization working, again with full-state meeting migration, from one Exchange environment to another:

Since we added sync for meetings we also did it for tasks and contacts. 

And of course this is fully-mappable and includes our UNDO capability for easy testing and disaster recovery.

Why don't we do email as well?  Because imapsync does a superlative job for 100 Euros for any number of seats!  We cannot beat that.  Actually I do not think anyone can beat that.

Given the popularity of our MDaemon to Exchange and Zimbra to Office 365 email migration guides we're seriously considering an Exchange to Exchange email migration guide for imapsync.  Stay tuned.

If you do not need or want all that utility we have an option that runs faster but still tells you who is supposed to be in your meetings.  This is the information no one else provides you.

If you need Microsoft Exchange to Microsoft Office 365 calendar migration, feel free to contact us.

Saving the configuration of an #MSFTExchange mailbox or meeting room as a CSV or TXT

We are no strangers to Exchange resources.

For those of you looking to save off the state of a conference room or resource in Exchange to a CSV please see Showing the Calendar Configuration of a Mailbox or Meeting Room using EWS by the incomparable Glen Scales for an excellent script.

You can also in an alternate simple method get the info in PowerShell and pipe it to save as a TXT file.

Get-CalendarProcessing  -Identity   Room_222@yourcompany.com  | fl > Room_222.txt

Your call what you need.

Printing a Paper Backup of Your iCloud Contacts

From today's New York Times:  Printing a Paper Backup of Your iCloud Contacts.

Folks are sometimes amazed when I pull out my long-treasured filofax.

Why does someone who worked on the first Personal Information Manager and the first group scheduler still use PAPER?

Simple.  Every calendar server and calendar client at Sumatra can become test data with no notice at all.  It's a principle as ingrained as our minimum two brain rule.

Paper doesn't suddenly disappear in a software meltdown.

We still haven;t added contacts to our Apple iCalendar to Exchange migration, but it also does not seem to be a big issue to anyone in a migration phase right now.

Sharing calendar and contacts in Office 365 - Microsoft's Guided Walkthrough

Because once you're done migrating into Exchange from a legacy system you want to USE the calendars and contacts you've brought in, you may wish to check out 

Sharing calendar and contacts in Office 365 Guided Walkthrough

Looking at the URL it's in the /common/survey directory so it's at least doing thinly-veiled double-duty as market research, but it has some good information.

You may also wish to refer to some of our earlier posts:

Shared Calendars in Exchange 2007 sp1  (still one of our most popular posts ever!)

and

Create a Company Shared Contacts Folder in Office 365

UNDO options in an #Oracle Calendar Server to #MSFTExchange migration

We were dealing with a client who needed to do an UNDO of a previous test migration and this meant we gave the site a concise summary of their options.

Of which there are three.

The fastest: dismount the stores, delete the database file(s) and logs, and then remount the stores.  This clears everything from all provisioned accounts!   This is the nuclear option on the data. It’s OK to do IN A TEST ENVIRONMENT.  It will cause a “resume-generating” action if done in production.  Remove the guest response database and start a new insertion.  Note that you will not need to re-provision the mailboxes. That’s what’s so good about this option:  Exchange remembers that accounts/users are already provisioned in Active Directory and Exchange recreates mailboxes once meeting invitations start flowing in.

Remember, if anyone else is working on the server, the nuclear options wipes their data.

Here's an example of how to script the removal of two databases "mbx01" and "mbx02"

d:
cd "D:\Ex13DB\"
Dismount-Database "mbx01" -confirm:$false
Dismount-Database "mbx02" -confirm:$false
remove-item -Path mbx01 -recurse -force
remove-item -Path mbx02 -recurse -force
Mount-Database "mbx01" -force
Mount-Database "mbx02" -force

Next fastest: Keep the guest response DB and do an UNDOALL.   This clears everything and the guest response table. Then delete the guest response DB and start a new insertion.

The slowest but safest: keep the guest response DB do a regular UNDO.  Then remove the guest response DB and start a new insertion.

Apple iCalendar to Microsoft Exchange Calendar Migration Demonstration

I know we said we'd do a video in January but even if this technology has not been out of our lab yet it's been looking so good that we needed to share it before the end of the year.

Thus: server-to-server Apple iCalendar to Microsoft Exchange,  In this case Microsoft Office 365 but it's really the same thing.



We're reading the Apple PostgreSQL database.  We heard murmurs of Oracle being a secret option in some cases.  Oracle would be no problem.  As a previous posts indicated, we're taking as much functionality as we can and adapting it to the target Microsoft Exchange environment.

You'll see our application running on a Windows 7 virtual machine on the Macintosh desktop.  We found it far easier to use our existing Windows code base than to start anew.

There's a few things we've sloughed off until later (like attachments to meetings / appointments, and contacts) that we just need to bounce some ideas around on.  But it's very functional.

We're working on integrating our migration to Open Directory so it'll be even easier.

Again -- if you have a hundred users, unless you are very convincing on how you're going to be an excellent and loquacious test site, it's just as easy to do a client-side export and import. 

For email always use imapsync.

If you're an enterprise with at least a few hundred users and need to migrate, drop a line.

Can't send mail in Exchange 2016 OWA -- unsent mail in drafts folder

All was well in our Exchange 2016 environment until our recent scheduled server outage in which I applied the latest Microsoft security updates.  Then mail stopped flowing:  all messages ended up in the drafts folder.    When this happened earlier in the year, I restarted the transport services:




# Restart When mail won't flow  (gets stuck on OWA Drafts folder)
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport




No change.  Looking in the event logs, I see a mountain of red.  That is never a good thing!  I notice event id 3003 -- MS Exchange BackEndRehydration.  The NT Authority\System does not have token serialization permission. 







Something got tightened down or changed.  Our first suspect: permissions. According to Microsoft KB Article 2898571, this is often due to effective deny permissions on the ms-Exch-EPI-Token-Serialization user right on the computer object.  Groups that are DENIED ms-Exch-EPI-Token-Serialization user right are:
* Domain Admins
* Schema Admins
* Enterprise Admins
* Organization Management




Check the group membership via group policy (run this cmdlet:)
gpresult /scope computer /r





UGH!  the computer is now part of the Schema Admins security group.  I removed the computer from that group and everything is fine.




For the sake of completeness, the Exchange computer should be a member of these five groups:

Domain Computers

Exchange Install Domain Servers

Exchange Servers

Exchange Trusted Subsystem

Managed Availability Servers

@Apple #iCalendar Full-State Migration to Microsoft @MSFTExchange / @Office365

Well we got wind of someone large enough wanting to migrate from Apple Mac OS X Server iCalendar into Microsoft Exchange that we went ahead and actually.... you know.... wrote a conversion method.  It's kind of eerie how much Apple's scheduling solution functions almost exactly like Meeting Maker (down to adopting some down-right goofy functionality like the calendar-only inbox for comments and the "first weekend day" of the month recurrence pattern). But that was probably to be expected.

We did this for El Capitan, so it's based on the iCalendar server being in a back end PostgreSQL database.  Making it work with an Oracle back-end would be no problem.  We read directly from the database and still allow user mappings and create live meetings on the Exchange side when we are done.

This is not yet field-hardened so please do not contact us looking to go into production this weekend.  We won't let you make a decision that egregious.

There's also the issue of how we instantiate Travel Time (it goes in as an appointment with a Free-Busy Status of "Out of Facility").  See our previous post.

We've ignored Contacts for the moment.

Some screen shots.

So this on the Macintosh calendar:

Will become this on Microsoft Exchange:

And of course, meetings are really MEETINGS with guest responses.  So on the Macintosh when Jimi invites Jerry to a meeting and Jerry accepts:

migrating this will carry it through to Exchange or Office 365 as a meeting:

Travel Time, a feature not supported by Outlook or Exchange but loved in Apple calendaring we've implemented by inserting appointments with the appropriate durations in advance of calendar events.

So this on Macintosh

becomes this on Exchange:

The sharp-eyed among you will note that this does something different from our previous post -- it kept the name of the "seed" event in the travel time description.  We experiment a lot with these things.  Any preferences?

Keep an eye on this blog for one of our videos showing this in real-time.  Probably after New Year's.  We've got a lot of migrations going on in December.

To give you an idea what the configuration for this looks like:

You're going to need to map resources to SMTP addresses (not a big surprise I hope).  You'll also notice above we set up the capability to read from a different Postgres database which makes it easier to copy your Apple iCalendar database to a more powerful Windows environment for insertion.

Make Google Calendar Stop Automatically Adding Events

From today's New York Times a good question and answer:

How do I make Google Calendar stop automatically adding events mentioned in Gmail?

Certainly it is possible but heed this warning: "Google warns that doing so removes all the past events added from Gmail."

This is totally bush-league!

Google should be ashamed they foisted that kind of slipshod capability on the public.

@Apple OS X iCalendar: “Travel Time” and Migration to @MSFTExchange or @Office365

Spoiler alert: We've been skunk-working a project for migrating Apple iCalendar to Microsoft Exchange and we've come up with a few things we should blog on.

First, read OS X Mavericks: Using “Travel Time” in Calendar.

Travel Time is a very cool feature and I remember sites asking for it when I was on Meeting Maker way back in the prior century.  

Apple implemented it.

The question becomes: what do you do with Travel Time in OS X Server El Capitan when you migrate calendars to Microsoft Exchange?

For appointments, it's very simple: you insert another appointment adjacent to the one with travel time and set it up with a reminder at the time you need to leave.

For meetings you do the same thing -- but as nearly as we can tell Travel Time only applies to the Organizer of the meeting (what Apple refers to as the CHAIR) not the attendees.  This makes it really simple for us, but as always, we put this out in the blogosphere for comments and for power users to say "not so fast!".

So what looks like this on the Macintosh for Janis Joplin:

Will become this on Office 365:

There's a couple of  things here that we're working with:

• Defining the Travel Time Free-Busy status on Exchange as "OOF" or "Away" as Office 365 now refers to it.  Somehow that seems more true to the intended spirit of the feature than "busy."  And "Free" is just right out.
• Since Travel Time is not defined with an actual name in the Apple iCalendar data structures we're going to keep all the times singular.  In English "3 hour travel time" makes more sense than "3 hours travel time."  (Those of a certain age will remember the immortal line: "A 3 hour tour....a 3 hour tour.")
• Reminder will kick off for Travel Time at the start of Travel Time.

One of the clever things about the Macintosh calendar user interface is that in monthly view the travel time does not appear  (heck, maybe it's a bug and no one's fixed it yet and everyone's really complaining about it -- but I think it keeps down on visual clutter).

So here's what a monthly view looks like for this event on the Macintosh:

And here's what it will look like in Office 365.  

A little advance training on your users will do wonders. 

#MDaemon to @Office365 International Migrations - Character Sets Deuxième partie

FOLDER NAMES!

Dagnabbit -- we forgot folder names in UTF-8.

This was one where the file system was replacing the “Tâches“ with “T&AOI-ches”

So we updated the code to handle it,

The latest build,  mCalreader_v4.1.17 addresses this issue.

To be safe, I recommend deleting these four lines in the XML config file and then re-running the code’s setup/configuration if you are already in a migration:

  

NB: Don’t worry if the config values look odd.  We save the localization values in “HTML-Friendly” format, so the “&” becomes “ampersand;”  (except in Blogger it gets interpreted into something not plain text)

For the curious, this is the table so you can handle your own cases:

           

Note that this is also a problem in email migration:  http://www.linux-france.org/prj/imapsync_list/msg01976.html

#MDaemon to #Office365 International Migrations - Character Sets

Let's say that you are happily migrating calendar data from MDaemon to Microsoft Office 365 or Exchange and you're someplace other than the USA with various accented characters.

Most times we've had no problem out of the box with the MDaemon calendar migration (and we see many migrations in Europe).

But one French site reported "é"s (as well as every other accented character) coming out incorrectly.  For example:

This is a classic symptom of the original character set being UTF-8 and that not meshing with the default Windows Western European character set.  Note that the e-acute in "Migré" was inserted under program control as a string already in the Windows character set.

No worries.

Modify the _Config_mCalReader.xml file to contain the following line:

Run your insertion.  It'll come out correctly in Exchange:

What if I forgot my #Oracle BEE_DATA Credentials in a Beehive to #Office365 Migration?

Our Oracle Beehive to Microsoft Exchange migration reads the Oracle database directly, which makes things WAY easier for a migration.

Using the BEE_DATA credentials gives us access to all the data email migration products do not take.

Recently though we had someone who inherited their Beehive installation and did not have their BEE_DATA password.

Yuck!  Normally we do not like to advise things like just changing the password on a running system, since you have no idea what else it affects.  As Buckaroo Banzai advised: "No, no, no, don't tug on that. You never know what it might be attached to." 

This script will create a user called “sumatraTestBeeData” with all the privileges we need.

--------------------------------------------------------------------------------------------------------------------------

--Using SQL*Plus, 

connect sys as sysdba/PASSWORD;

select tablespace_name, status, contents from user_tablespaces where tablespace_name like 'bee_%';

drop user sumatraTestBeeData;

--create user command:

CREATE USER sumatraTestBeeData IDENTIFIED BY PASSWORD  DEFAULT TABLESPACE BEE_DATA TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON users  QUOTA UNLIMITED ON BEE_DATA;

grant sysdba to sumatraTestBeeData;

grant create session to sumatraTestBeeData; 

grant ALL privilege to sumatraTestBeeData;

Grant UNLIMITED TABLESPACE to sumatraTestBeeData;

--sumatraTestBeeData needs access to these three tablespaces:

--BEE_DATA, BEE_LOBS, BEE_INDEX

alter user sumatraTestBeeData quota UNLIMITED on BEE_DATA;

alter user sumatraTestBeeData quota UNLIMITED on BEE_LOBS;

alter user sumatraTestBeeData quota UNLIMITED on BEE_INDEX;

--------------------------------------------------------------------------------------------------------------------------

Then use these Beehive credentials in bCalReader:

Full-state Calendar Migrations from #Oracle, #Zimbra, #MSFTExchange, etc into @Office365

There must be a forest around here somewhere, I just cannot see it through all these trees.

These are Sumatra's full-state calendar migrations into Microsoft Exchange that 

• re-create meetings
• keep recurrence patterns 
• preserve guest responses. 
• book conference rooms and resource
• make it like your users have been using Outlook and Exchange all along. 

• Everyone else who claims to do calendar migrations skips over all this functionality. To be fair, it is hard to execute correctly (and most of them have their hands full convincing you to do email when imapsync does it so well and so much less expensively), and it's not too important if you have a few hundred users. But it is the whole ball of wax if you're any real-sized corporation.

Exchange to Office 365

with Incremental Sync

Oracle Calendar Server to Exchange / Office 365 (via ICS files, which we still use to create live meetings):

Oracle Beehive to Exchange:

MDaemon to Exchange (we don't do full-state on this)

Meeting Maker we've been doing but we didn't do a video on it.  And at this point -- why bother?

Zimbra to Office 365:

Check out Setting the Colour of a calendar using EWS and Powershell in Exchange

Those of you looking for instructions on Setting the Colour of a calendar using EWS and Powershell in Exchange should head over to Glen's Exchange Dev Blog.

Microsoft and Linux: Sign of the End Times?

My amazement is complete.

Read: Microsoft Built Its Own Linux Because Everyone Else Did

Never would'a thunk it.

For Exchange it makes PERFECT sense -- but I would have bet against this ever happening.

Enterprise Calendar Migration @Zimbra to @Office 365 @MSFTExchange

Per request, a video of  migrating calendars from Zimbra into Office 365.

Of course this keeps meetings as genuine, functional, updateable meetings when they are migrated to the Microsoft Exchange side.

We are reading calendar data directly from the Zimbra database, a technique we also use for our full-state Exchange to Exchange migrations and our Oracle Beehive to Exchange migrations.

Microsoft Deprecating the REST API preview endpoint

Microsoft is Deprecating the REST API preview endpoint on October 15.

Now this is the PREVIEW endpoint, not the functionality.

Since we're on something of a roll, we're considering using REST to pull calendar, task, and contact data out of Zimbra at some point.  Our experiments make pulling the data from Zimbra look relatively straight-forward.

Our experiments putting data into Office 365 indicate more trouble and uncertainty than it is worth -- so we're likely to stay with our current methods.

Converting a Meeting Maker server to a relational database

We had someone ask us "Can you guys convert a Meeting Maker server to a relational database?"

Short answer is: Yes - that's how our migration process has always worked.  Raw Meeting Maker data exists in an object-oriented database format that I have described as a cross between a PhD thesis and a junior high school science project. 

Even though we formally ended our MM to Exchange migrations we've been contacted by some Friends of Sumatra who've been through migrations with us before so we've kept our conversion software running.

Time frame: depending on how much history you have and how many users are on your Meeting Maker server we can convert your data into an Microsoft Access database in (at the most) an afternoon.  Usually it's only a few hours but breaking out and spinning up the conversion server is the real hassle.

This converted database alone is insufficient to run a full migration into Exchange.  Do not allow that idea to entertain your mind.

The converted database is completely appropriate for converting / archiving Meeting Maker servers into a standard database format so that you can do searches for legal compliance, history, investigations, or whatever your data-driven needs require.

#Zimbra Email Migration to #Office365 using #imapsync

Today we'll show you how to use imapsync to migrate email from Zimbra to Exchange 2013 / Office 365.  We got some good feedback from our initial post on Zimbra calendar migration to Microsoft Exchange and wanted to add some value on the issue of email migration.  When we did that for MDaemon everyone was very grateful and it led to much calendar migration.

You can license the technology and purchase the support to migrate your email for 100 Euros. Remember this only moves email.  You will have to budget additional funds to move your calendars.  This gives your end users a complete solution -- email and "live" (with guest lists and responses.) Plus, your conference rooms and resources are fully functional when you're done with your migration.  That's what we do at Sumatra.

We found imapsync to be the most  efficient and cost-effective, email migration product.  Just license imapsync and get support at the same time.

Is this imapsync email migration guide exhaustive?  Hell no!  There is no way to document all the "creative" ways user behavior can wreak havoc -- and some of them are going to be downright pathological.  We are aiming for the 80% side or the 80/20 rule here.  You get that much down you can make a good stab at the rest if you find yourself in difficulties. Barring that imapsync is very forgiving and its model of incremental syncing is laudable in its simplicity and effectiveness.

Migrating your email probably also takes you through 80% of what you need in a migration.  If you're happy with that -- glad to be of service.  If you need the calendaring to come over with fully-functional meetings, guest lists, responses, resources, contact Sumatra and we'll set you up with a trial.

Preliminaries

Zimbra has excellent guide on using imapsync with Zimbra.  We would suggest you add a valid non-self-signed certificate to their requirements.  imapsync runs in Linux and Windows (via the Command Prompt.) We'll demonstrate the Command Prompt since Microsoft Exchange / Office 365 is our target system.  Editorial comment: one of the smartest things Microsoft could do is put Exchange on Linux, but it's more likely some weenie there will recommend porting Windows to the iPad first.

Remember before you test,  you will have to enable IMAP in Exchange 2013 and for your end users in Office 365.  See how to do this in our blog post.

Migrating one user Zimbra to Exchange

In the simplest case migrating from Zimbra to Office 365 looks like this for our user Jimi Hendrix (if you use individual passwords for users).

imapsync.exe ^

--host1 sumatra.com --user1 jimi.hendrix@sumatra.com --password1  "XXXX" ^
--host2 outlook.office365.com --user2 ^
jimi.hendrix@sumatra.onmicrosoft.com --password2 "XXXXX"  ^
--ssl2  --sep2 /

If you set up a service account with FullAccess on Office 365, you accomplish a migration without knowing any password except your service account by using a command like this (where password2 is the service account password):

imapsync.exe ^
--host1 zimbra.sumatra.com  ^
--user1 jimi.hendrix@zimbra.sumatra.com --password1 "XXXX" ^
--host2 outlook.office365.com --port2 993 --sep2 / ^
--user2 jimi.hendrix@sumatra.onmicrosoft.com ^ 
--authuser2 SERVICE_ACCT@sumatra.onmicrosoft.com ^
--password2 "XXXXX"  --ssl2

Note in  the above, for an Office 365 target system we need to use the "--sep2 /" command. 

Confused about Exchange permissions and setting up your service account?  Read our post The Cookbook Version of Exchange 2013 Migration Rights.

If you want to use a Service Account on Zimbra as well, similar syntax should work using either the "admin" or "zimbra" account.

Note also that this gives you the direct capability to map your user ID, for instance from "jimi.hendrix" on your legacy system to "jhendrix1967"  or "jimi.hendrix1967" on your target system.

Iterating over a user list

In any event you are going to need to generate a user list to migrate email.  Can you keep your migrating user list separate from your migration script?  Answer: YES. This method assumes your legacy ID is the same as your target ID, but allowing for this to change is not a hard extension.

The imapsync ZIP file contains a script for iterating on a user list:

sync_loop_windows.bat

Which also contains an excellent primer on running imapsync in parallel.  

This batch file assumes a text file in the form "User1;Password1;User2;Password2;..."

Zimbra's Guide to imapsync includes a couple of batch processing script examples.

To get  a user list from Zimbra you can use either zmprov (this gets a list of accounts without passwords, so use a Zimbra admin account to get data, and please edit out the spam, A-V, etc. IDs): 

cd /opt/zimbra/bin  

and 
sudo ./zmprov -l gaa >~/accounts.txt

You could also use ldapsearch if you already have scripts for that. 

It has been said that the "death is in the details."  We say, "success is set in the details."

Now come the details

Throttling in Exchange/Office 365: Your Migration Nemesis

Note that I did not write "enemy."   You're more likely to be throttled in Office 365 since the controls to that environment are largely out of your hands.

As per our usual mantra: test everything before you go into production.  

If you get throttled, there are two imapsync switches you can tweak.

One limits the transfer rate to a specific number of messages:  
--maxmessagespersecond

Start at 10 (say) and work up or down from there.  In calendar migrations we start with 25, but our gut experience tells us calendar data is smaller per object on average.

The other limits the transfer rate by byte if that works better for your network environment.

--maxbytespersecond

You can also check out our post Throttling in Exchange 2013.

Really helpful options

• --buffersize 8192000  imapsync has a default I/O buffer of 4 Kb.  Upping this to 8 Mb will probably speed things for you
• --syncinternaldates: some email systems misuse email dates and you therefore run the risk of the receipt dates on your target system (what imapsync refers to as host2) becoming the date of insertion.  This command avoids that unfortunate event. 
• --fast:  this prevents flags from being synced and therefore makes the process (wait for it....) faster.  Not an option to invoke if you want / need to sync flags! 
• --dry:  this is a really useful option for development and debugging,  It just goes through the motions of logging onto both source and target system and displays the status -- a dry run.  Use this or debugging options -debug and -debugimap

Other idiosyncrasies

The imapsync FAQ recommends these additional settings when migrating from Zimbra.

imapsync ... ^
--exclude "Conversation Action Settings" ^
--exclude "Quick Step Settings" ^
--exclude "News Feed"

Although we have not seen those folders in Zimbra in a while, your implementation could be different.

Sent, Junk, and Trash

However, there are differences in Folder names between the two environments that may be relevant to you.  Specifically what Zimbra calls "Sent, Junk, Trash" Office 365 calls "Sent Items, Junk E-Mail, Deleted Items" as seen in this side-by-side comparison.

To successfully migrate these folders, use this command sequence to map the folders: (see Zimbra Documentation):

--regextrans2 's/Sent$/Sent Items/'
--regextrans2 's/Junk$/Junk E-Mail/'

--regextrans2 's/Trash$/Deleted Items/'

Notice how we lined these up so it would be easy to repeat if you needed this for other systems, or different language packs.  These being regular expressions you could also take several related folders and migrate them into a single one on the Office 365 side, but I leave that to your wits and imagination.  If you do find something that works, let us know -- we'll update this post (of course, crediting you!)

Exchange IMAP Prerequisites

Did you configure IMAP?  If not, see how in our blog post:

On the Zimbra side:
Make sure you are enabled for IMAP access. 

Check "Enable clear text login" for the IMAP service via "Global Settings" or under "Servers" under IMAP in the Zimbra Administration Console.

If you need to install Perl modules, this is an excellent tutorial on how to do so.

Sample Scripts

These sample scripts for major migrations / multiple users will help you out a lot.

http://imapsync.lamiral.info/examples/sync_loop_windows.bat

http://imapsync.lamiral.info/examples/file.txt

Final word on really considering what you need in Zimbra migrations Diatribe: Migrating email is about moving tonnage.  Migrating calendars is about preserving responses, recurrences, and resources.

But a full migration methodology has to include more than just moving this data. We have a comprehensive suite of scripts and tools so that before any email or calendars are migrated we take care of:

• Reading the Zimbra user list (and passwords)
• Provisioning users in Exchange
• Re-configuring Outlook to point to your Exchange server and removing the Zimbra Outlook connector. (Note: there are publicly available scripts but we wrote our own after we found they did not work.)
• Pre- and Post-cut over scripting so that legacy emails are moved to the target system, and new emails redirected to the target system.

If you have a few dozen users, it's difficult to make an automated process cost-effective and you might as well do it on your own one at a time.  You can export PSTs or export files from Zimbra, then import those PSTs into Exchange.  Tedious and time-consuming, yes, but free.

If you are a larger site with the need to preserve your meeting guest lists, recurrences, responses, and resources post-migration feel free to contact Sumatra.