How to fix: 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine

Our full-state calendar migration executes on a 32-bit or 64-bit architecture.  We default to using the JET database engine, though this can be changed in _Config_XML:

 Provider=Microsoft.ACE.OLEDB.12.0;Data Source=

If you don't have the x64 version of MS Office 2010 installed, (or NO version of office installed) download the Microsoft Access DB Engine 2010 Redistributable (pick the x64 version!)

http://www.microsoft.com/download/en/details.aspx?id=13255  Install the x64 version via the Command Prompt with: 

AccessDatabaseEngine_X64.exe /passive

Do it this way OR you'll see the error:  The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.

The error will look like this in the error window of our migration tools:

 If you look in _Config_XML you will see the default (top line) as well as the other options should you need to change them.

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=

PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=

On .NET Framework 4.6.1 and Exchange DANGER!

Please read On .NET Framework 4.6.1 and Exchange compatibility and then DO NOT install .NET 4.6.1.

Step away from the installer.....

Because if you allow it, to quote Microsoft "Mailboxes are quarantined and databases fail over unexpectedly in Exchange Server 2013."

Follow-on to January 1, 1970 and your iPhone

In the annals of "why there?" starting dates for calendar systems, the iPhone is not alone.

Consider UNIAPI_TIME for Oracle Calendar System (a relic of when it was Steltor and prior to that CSandT).

So if you're using OCS and do a UNICPOUTU export (aka the OLD way of doing a full-state calendar migration with us) you'll see lines in the data files that look like:

K Events:

S 9699600

D 30

T J2J

G CR Mozart

I 0

R N2

M Hendrix Jimi

W Hendrix Jimi

A TRUE 0 10

C [ .+] Hendrix Jimi

C [ .-] Garcia Jerry

O 

That "S" entry is the start time measured as the number of seconds since January 1, 1991 at 00:01:00 AM.

And of course you need to be careful of this since the great North American DST redefinition.

Email Migration Microsoft Exchange to Office 365 via imapsync

Yet another in the ever-expanding popular series of how to use imapsync (one of the best low-cost tools available) to migrate email to Exchange.  This time for Microsoft Exchange to Microsoft Exchange or Office 365.

Yes.  Microsoft offers tools for this, and we've documented them.

Evaluate them yourselves.  We have.  That's why we recommend imapsync. Full disclosure: we have no relationship with imapsync and derive exactly zero revenue from this non-existent relationship.

We see a wide spectrum of Exchange expertise (*cough* admin at university in Pennsylvania stymied by Junk E-mail folder *cough*) so we think it's useful to document this process.

Your comments are welcome and will be added and credited.

First step:
Make sure you are enabled for IMAP on both sides of your Exchange migration. 
We've gone over this in our post Quick guide to Enabling IMAP in @Office365 / #MSFTExchange 2013.

Second step:
Set up a Service Account with access to all your Exchange accounts. Confused about Exchange permissions and setting up your service account?  Read our post The Cookbook Version of Exchange 2013 Migration Rights.

Third step:
Test this before you do something rash.

Gilles (imapsync's AWESOMELY capable  author who deserves HUGE credit for his application) has a sensible method of beginning in his sample batch file (seen in this excerpt):


...

@REM Three other options are in this example because they are good to start with
@REM
@REM --dry makes imapsync doing nothing, just print what would be done without --dry.
@REM 
@REM --justfolders does only things about folders (ignore messages). It is good
@REM               to verify the folder mapping is good for you.
@REM
@REM --automap guesses folders mapping, for folders like 
@REM           "Sent", "Junk", "Drafts", "All", "Archive", "Flagged".

@REM

...

Or: do a DRY run, make sure it's handling the folders you want, and let the application guess on your folder mapping (for Microsoft Exchange to Office 365 or Exchange not complex).

Not too controversial or inscrutable, right?

So for ONE USER where you have the password for that user on BOTH systems start with:


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 /  --dry --justfolders --automap

once things are doing what you want, you can turn this into:

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 /  --automap

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  --dry --justfolders --automap

remember --dry --justfolders are for debugging.

Note in  the above, for an Office 365 target system we need to use the "--sep2 /" command. 
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;..."  (TIP: If you use a service account you will not need the password)

To get  a user list from Exchange get-mailbox is the simplest method :

get-mailbox | fl name,emailaddress   > myusers.txt

to give you full name, email address.

For just email address run:

get-mailbox | emailaddress   > myusers.txt

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

If you want to get a list of all users in an OU to migrate by segments: 
get-mailbox (e.g., -organizationalunit users

More Migration Details

Throttling in Exchange/Office 365
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: Not for Exchange, but 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

See our section on Common Problems and Solutions in our Sumatra's DIY Guide to an Office 365 Migration.

January 1, 1970 and your iPhone.

Four words: Do not do it.

See:

Why the 1970 Bug Bricks Your iPhone

An interesting variation on this to experiment with would be to go back to the 1960s, insert some calendar entries and watch what happens, but I'll leave that for you in the "willing to sacrifice my smartphone for the sake of science" crowd to try that out and report on.

Brings back a couple of incidents where back in the days of Meeting Maker migrations one of the characteristics of bad data was pre-computer era dates (like the 1940s) in corrupted calendar entries. So figuring that we ignored any dates before 1990 if we got them in a Meeting Maker server.

Then one day we found a site with a user who actually ENTERED DATA BACK TO THE 1950s!  Mainly birthdays.   

Slow PowerShell Response to Get-Mailbox Debugging Protocol

Gentle reader of calendar migration intent,

Ms. Calendar received the following (edited slightly for clarity):

When setting up an impersonation account in our active environment the first few steps (editor's note: see The Cookbook Version of Exchange Migration Rights) go fine and then when I run this:

Get-Mailbox -resultsize unlimited | add-mailboxpermission -user OurDomainUser -accessrights:  fullaccess -InheritanceType: All

It just sits there and never spits out any output.  Yesterday I left it running for hours and eventually Exchange Management Shell closed itself but I still get the you don't have access to this email when trying to log in to any email accounts with the service account.

An  interesting case which does occur! 

There is not a lot of love across the community for Get-Mailbox performance and even less for practical actions to take.  See: Performance issues with Get-Mailbox -Database PowerShell cmdlet and Count Mailboxes Per Database Faster.

Hats off and thanks to Russ and his team for this migration-centric debugging protocol:

It is probably a problem with "get-mailbox"

To test:

1) First try without any qualifiers: 

get-mailbox  

or limit it to 100

get-mailbox  -resultsize 100

2) Second add the resultsize qualifier

Get-Mailbox -resultsize unlimited

Once they set a static limit instead of unlimited they were able to set impersonation on all accounts.

We have seen in instances where the performance is deplorable it's usually a problem getting the "join"s to work through AD.  Keep in mind we're linking two separate AD actions here, Get-Mailbox and Add-MailboxPermission.

Where is the AD server located? 

on the same subnet? 

Are there access issues there?   

To test if it's a connectivity issue, use PortQry to check for connectivity issues. You can download it from Microsoft. Test ports 389 (LDAP) and 3268 (Global Catalog).  There are other possible ports, but these are the main ones used.

On the related issue when you have trouble with Exchange performance itself, see Troubleshooting performance issues with Exchange when RPC request spike high.

Update to #Zimbra to #Office365 Email Migration using @imapsync

As an update to our post #Zimbra Email Migration to #Office365 using #imapsync  

On the issue of mapping folder names, use imapsync 1.678 and its 

--automap option.  This is now pre-populated with best guesses for Exchange as a target (if I read the release notes correctly)

If --automap does not work directly for Zimbra to Exchange, then use

--f1f2 str1=str2 

for example:

--f1f2 Junk=Junk E-Mail to map Zimbra's "Junk" folder to Exchange's "Junk E-Mail."