Oracle Meeting Scheduling Practices and Microsoft Exchange Best Practices

There are several common OCS meeting scheduling practices we need to document, so you, in turn, can educate your users about the differences between scheduling meetings in OCS and Exchange.

FIRST:  Oracle Calendar Server allows a user to organize a meeting and then remove themselves as an attendee.

THIS BEHAVIOR IS IMPOSSIBLE IN EXCHANGE! In fact if users manage to figure out how to do it’s one of the ways to really damage calendar data in Exchange.  We feel it our duty to recommend our customers adopt Microsoft Exchange best practices.  Thus, we do not recommend this behavior get replicated in Exchange.  To help you find and fix those meetings, we have integrated a pre-processing diagnostic step to both diagnose and remedy the issue. 

What it does is to re-create ICS files for the affected users and their meetings.  These files are then inserted using the standard Sumatra process.  The reports allow you to proactively notify or involve any critical calendaring users that they are going to be added to the meetings they though they removed themselves from.

How this works / what you need to do

1.   Export ALL your ICS files into a single directory.  You need to do this anyway for the migration process.

2.   If you create a separate directory that contains the oCalreader, please configure it, and point to the ENTIRE export of ICS files created in step 1

3.   Press the Organizer not Attendee button. Note: this might change in some versions of the tool.  You will have to check “Show Migration Steps”, and then you can click the Organizer button.

                                                        

4.       The tool outputs things in TWO directories

a.    The “Logfile” directory contains three files: the summary text file, along with the two CSV files for the Organizer not Attendee accounts.  These tell you which meeting organizers are affected by this situation.

b.    A subdirectory of the iCalData path gets created called “SpecialICSUsers”. The tool regenerates the ICS files that contain JUST those problem meetings -- and adds the organizer back to the meeting.  This is where the newly generated ICS files are stored

5.      It is possible there are situations where not all meeting organizers’ ATTENDEE record can be found.  Look in the SpecialICSUsers subdirectory, and see if there are any files that start with “_noattendee_”. You will have to figure out how to handle these users/meetings.  For example, if you might see a file called “_noattendee_sarah.jane.smith.ics”. You will have to either have the organizer to the meeting by hand, ask the organizer to add him/herself to the meeting in OCS and then re-export the ICS files, or choose not to migrate the meeting by deleting the files.

6.      oCalReader also checks for missing or invalid email information.  The resultant file is written to the “logfile path”, and called “AccountMissingOrInvalidEmail.txt”.  Read and act on these in advance of your cut-over into production.  For example:

CN=Clara Oswald:mailto:""

CN=Companions Conf Rm:mailto:""

CN=Companions Conf Rm:mailto:100000518943623636038552@email.invalid

CN=Medieval History Room:mailto:""

CN=Medieval History Room:mailto:182D1D7DF8E9ECA5E050C68489657375@email.invalid

CN=Martha Jones:mailto:""

CN=Martha Jones:mailto:100000250843623636038553@email.invalid

                                               

The logfile shows two users, Clara Oswald and Martha Jones, no longer have email addresses (are they terminated accounts?)  It also shows two rooms with problems.  You will have to add those rooms, “Companions Conf Rm” and “Medieval History Room”, to the resources map file to map those accounts to valid SMTP addresses.

7.       Finally to insert meetings where oCalReader has added the organizer back to the meetings, follow these steps:

a)       In the ocalreader directory include your accounts and resource mapping file(s)

b)       Edit the oCalreader Configuration

i.      Change the ICS data file directory to the “SpecialICSUsers” subfolder

ii.     Ensure there are no “limits” set

8.   Push “Read and Insert”

Note these assumptions:

• We add the organizer back to the entire series to preserve recurrence patterns and the integrity of the meeting -- even if the organizer cancels their presence on some (but not all) of the instances.  Implication: There is the potential for duplicated meetings if some occurrences do have the organizer present.)
• We set the organizer to ACCEPT the meeting (that happens by default).  Because the organizer removed themselves from the meeting we set their Free/BUSY status to FREE UNLESS the organizer has set the series to BUSY (then it becomes busy).
• For the very curious this is a full ICS generated by this process.

SECOND:  Oracle Calendar Server allows resources to be meeting organizers.

In Exchange unmanaged public resources should NOT be organizers, but we relax this in certain cases to migrate data.  Why should unmanaged public resources not be meeting organizers?  Resource accounts are DISABLED by default.  As with many rules there are exceptions.  It is perfectly acceptable to have a room direct booked or managed by a delegate (for example: “CEO’s Private Conference Room”).

If you choose to allow direct booking into conference rooms:

Exchange, by default, strips both the subject and owner in the resource calendar

If you wish to retain this information (which is common in Oracle calendar)

You will need to execute this command for those resources: 

set-calendarprocessing  : -deletesubject: $False -addorganizertosubject: $True

This has privacy repercussions!  Showing subjects and organizers reveal potentially sensitive information, such as (these fabricated examples): “Interview James Bond to replace Provost”, “Implications of the 2019 500% Tuition Hike on staff reduction plans” booked in the “President’s Conference Room.” 

You have been warned.

If you do want to determine which resources organize meetings, the “Organizer as Attendee” component generates a file, ResourcesAsMeetingOrganizers, which lists of those accounts. For example, if the Doctor as a designate to the “Tardis Control Room” proposed a meeting on behalf of the “Tardis Control Room”, called “How to use the New Dimensional Portal Controls”, the ResourcesAsMeetingOrganizers file would contain:

CN=Tardis Control Room:mailto:doctor@drwho.timetraveller.org

THIRD:  Oracle calendar server allows resources emails to be assigned to a user account.

In Exchange resources have their own SMTP accounts.  OCS allows the OCS administrator to assign a designate/delegate email to the room (so messages are sent to him/her. For example, the Tardis Break room has an email address that belongs to Amy Pond

ORGANIZER;X-ORACLE-GUID=269167A2DA4992BCE050C6848965230C;CN=Tardis Break Room:mailto:amy.pond@drwho.timetraveller.org

                                                                      

What are your choices?

1)       REMOVE the email address from the OCS rooms and re-export the data;

2)       Leave it unchanged, the designate will become the organizer of the meeting, something that they will not be happy to see on their calendars.

3)       Figure out how big a problem this is.  The “Organizer as Attendee” button generates a file, ResourcesWithUserEmails , that shows the list. For example, the file would contain:

CN=Tardis Break Room:mailto: amy.pond@drwho.timetraveller.org

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."

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.