#zimbra client-side vs server-side calendar ICS exports for @MSFTExchange migration

Gotta give props to the guys at Zimbra.

Usually when there's client-side export method and a server-side export method, the results are different.

Here, exporting calendars as ICS gives exactly the same result regardless of doing it client-side (via Preferences-Import/Export)

Or server-side via zmmailbox

And here's the proof.  But stay tuned next week for some additional consequences of different clients on the Zimbra calendar and what it means for migrating calendars in a scheduling-centric enterprise.

..

#Oracle Calendar Server migration to #MSFTExchange: Users OUTSIDE your organization

Got this question in:

What do the partial and full Oracle calendar server migration options do with meeting invitations to guests outside the organization? 

Gentle reader of calendar migration-mindedness:

Re-sending proposals to users outside your domain is OPTIONAL, as below in yellow.

In general – this is confusing as heck to outside users, since they’ve already responded to an invitation and you probably do not keep them all informed about your migration plans. Your internal users KNOW a migration is going on (well, most of them, let's be realistic). But you have ZERO control over users outside your domain.

In general we recommend you NOT re-send them (though we've had one or two that demanded it).

We insert the address in the agenda, so it’s straightforward to keep track of these and add them post-migration if a meeting updates (which is the real issue)

Your call, but I’d treat it as a training and post-migration issue.

@Zimbra Enterprise Calendar Migration to @MSFTExchange Options

So we have one enterprise site that is serious about migrating calendars from Zimbra to Exchange 2013.

Again, we're talking full-state, live meeting migration we do, not the semi-functional, "well it's a calendar, so what if the meeting changes don't update now?" that some folks settle for.

This has caused us to look at our migration methods for large-scale Zimbra to Exchange calendar / tasks / contact migration.  We've got a long-standing weirdness.

In Zimbra an attendee can DECLINE a recurring meeting and ACCEPT a single instance.

This is NOT allowed in Exchange.  You decline a recurring meeting in Exchange and it is gone.

So what we've done in the past is have the attendee accept the series and decline all but that one instance.

We're re-thinking this and might just make the single acceptance a one-time meeting with appropriate modifications on the master recurrence pattern exceptions.

Strong feelings about this?  Let us have your feedback.

Au revoir #MSFTExchange PST

Our love/hate relationship with PSTs is well-documented in our postings.

It is therefore with an odd sense of both elation and dread that we see Redmond itself advocating Deep Sixing PST Files !

Elation is obvious. Dread because.... what proprietary data format horror will they come up with next?

Still, a good read with excellent references for how to handle your transition.

Windows 10 and Calendar / Contact Privacy

For those of you who have upgraded to Windows 10 (and if you had Windows 8 this was a no-brainer), you HAVE to read:  Windows 10 is spying on almost everything you do – here’s how to opt out and Windows 10 defaults to keylogging, harvesting browser history, purchases, and covert listening and Digging into and Understanding Windows 10’s Privacy Settings. 

The most sober reading I've seen comes from Lifehacker.

Now since we're calendar geeks, we're going to show you how to keep your calendar and contacts private, which should be the default in the first place, but is not.

You do not have many choices in your Calendar.  If you want to use Cortona to set your appointments, it needs to check your calendar.  If you are worried Cortona is a nosy rhymes-with-witch who is ratting you out at every opportunity, then turn this off.

You have more choices in your Contacts -- but what "App connector" and "Windows Shell Experience" are is 1.) unclear 2.) why these are options for contacts but not calendar and 3.) WTF?  Microsoft support ducks the question not only about what they are but why they need specific access.

Short answer: beats the heck out of me -- but I dialed my privacy settings to the max.

My main previously unanswered question:  I'm happy with Windows 7 on my desktop.  How do I get rid of the Microsoft annoyanceware in my lower left hand corner?

Simple.

Click that nearly invisible "Up" triangle:

Then select: GWX "Hide icon and notifications"

Yeah!  I get to keep Windows 7!!!!!  And NOT be badgered about it!!!!!!

Our conversion server for Meeting Maker to Exchange still runs Windows XP.  I needed to take the darned thing off the network to make sure Microsoft / Java / Whoever didn't "improve" it by making it unusable with an automatic update.

Mitigating bad user behavior during an #Oracle calendar migration

Got this from the field a few weeks back:
What if we set up inbox rules on each migrating account to redirect invites and responses to some other (non-INBOX) folder - would oCalReader still be able to find them when it comes time for it to respond and clean up responses?

Please do not do this.
Since Exchange delivers the invites to the root mailbox we look at the root mailbox.
Any other folder is strictly verboten.

But -- what you can do:

• Disable Outlook access for the migration period.
• Hide the conference rooms in the GAL (stops a preemptive land rush from users -- this HAS happened)
• Shut off ActiveSync/BES (handhelds are actually a bigger problem than Outlook)
• Tell your users we know who's been naughty or nice from the logs

#MDaemon calendar to #MSFTExchange Migration Trial

Is available here.

For documentation start with this and look at our other posts.

For email you can use Microsoft's tools. but we've found imapsync more effective.

#Oracle Calendar Server to #MSFTExchange Migration and Years of Historical Data

Our latest version of Oracle Calendar Server to Exchange migration will allow you to surface a keyword in our XML Configuration file.

If you're in trial with us now we've told you about it.

If you get a trial from us and this is relevant we'll clue you in on what to do.

But basically you will split up your migration into two runs: the "Current" and the "Historical" -- and for each run you want different keywords.  Why?  So that if something goes wrong in the second run you can remove only THAT data and not the data you inserted before.  At Sumatra we're always looking out for you guys.

For historic data, we recommend inserting without sending email invitations – the process will go faster and you will still have the guest list in everyone’s appointments.  Use this setting:

It’s like “printing” your calendar into Exchange.

So the meetings are not live meetings (but they’re historical so – what’s the problem?) – but everybody’s who had a meeting or appointment in their calendar will have it in their calendar post-migration.

One other thing: For testing using the date range in ocalreader's "Calendar Selection Dates" configuration option is fine.

For a production run, use OCS's UNIICAL date ranges to specify the date ranges in your ICS files.  Why?  You ask.  Fair question.

If we interrogate the date and get a null answer in a migration into production, we’re spending cycles checking when we could be inserting.  This inefficiency adds up over lots and lots of data.

Final word: be careful managing the keyword.

Resources before and after your Microsoft Exchange calendar migration

Please consider this a follow-on to Russ's previous post.

We've got scads of migrations right now at various phases and something that keeps coming up is resource handling ("surprise, surprise" which I always imagine in a Gomer Pyle voice).

Before inserting calendar data into resource calendars, use PowerShell to enable all mailboxes and to disable automatic calendar processing, scheduling horizon, and conflicts.

To enable all resource accounts (pre-migration): 

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | enable-mailbox 


This script will disable automatic calendar processing, scheduling horizon, and conflicts for ALL resources: 

Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | 
           Set-CalendarProcessing -AutomateProcessing None
           -deletesubject:$False -AllowConflicts: $true 
           -EnforceSchedulingHorizon: $False

Post migration you can set these to whatever policies you wish -- but this allows us to re-create the calendar as it was in your legacy system.  A lot of field data has conflicts and double-bookings which get decided closer to the date.  The scheduling horizon on some legacy systems is 2039.

Post-migration to set resources to autoaccept which in Exchange 2013 is done via set-calendarprocessing:


Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | Set-MailboxCalendarSettings -AutomateProcessing AutoAccept -deletesubject:$False -addorganizertosubject:$True

Post-migration to DISABLE all resource accounts:

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | disable-mailuser

For private conference rooms you may want to set some policies like “book-in”, “request-in” that allow admins and other authorized people to either send in a meeting request, or be allowed to book a meeting in the room. This way the admin, as a delegate to the boss, can create a meeting in the boss’ calendar and invite a room. And everything flows through Exchange without issue.  A Look at Exchange Server 2013 Resource Mailboxes goes into good detail showing you how to accomplish that.

You don’t want to have rooms organize meetings because they are disabled accounts and cannot respond to email traffic.  Since this is a feature of the ICS exports from Oracle Calendar Server there is little we can do to remedy that situation (since OCS does not indicate the human who should be organizer). 

If you are migrating “shared” calendars, e.g., “carpool van”, “IT vacation schedule”, ”Help Desk Coverage Assignments” then create that entity as a user account in Exchange, migrate the ICS resource data into that entity, and then re-type the account from user to “shared.”  We wrote about the right sequence for migrating Shared Calendars into Exchange and setting them up.

Final note: now keep in mind: this is relevant to do the kinds of calendar migrations we do where meetings are actual meetings when you get done.  For every other kind of calendar migration out there you can ignore this and focus on having your users re-create all their meetings.

Two ways to grant access to a Resource in #MSFTExchange

A client asked us to explain the difference in the two ways for an end user to have "delegate" rights to a conference room.  It is confusing -- Microsoft calls them both "delegation"  and tried to explain them in a recent Exchange Team Blog post, Booking Delegation Vs. Classic Delegation.

Here is the summary:
1. Grant delegate permission using Outlook or OWA (aka "Classic Delegation")
2. Grant delegate permission using Exchange Control Panel (aka "Booking Delegation")

There are three problems with the "Classic Delegation" for conference rooms:

• First, since rooms are "disabled accounts", it's hard to log into them.  
• Second, Classic Delegation creates two rules -- one visible (IPM Subtree folders), and one invisible (think NON-IPM Subtree folders.)  When you change/remove a classic delegate, the hidden rule does not always get deleted and thus still remains in force. (Why? Outlook tries to be helpful, and when it sees there is a hidden rule, it uses the hidden rule.) 
• Third, the classic delegation rules run at a higher priority than  booking delegation rules.  More ways to confuse administrators.

Moral of this story: don't use Classic to delegate access to rooms. Sumatra urges all our migration customers NOT to migrate delegates -- once set they are difficult to remove (see our post from '08).


Sumatra recommends you assign room delegates using the "Booking Delegation" approach.  You can either use Exchange control panel to assign booking delegates, or PowerShell.  We prefer PowerShell.

There are several things you must do, depending upon how you want to handle room reservation requests

For auto-booking:
Ensure automated processing of meeting requests is set.
Example: Set automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing AutoAccept

For a managed room:
1. Ensure automated processing of meeting requests is disabled.

Example: Disable automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing None

2. Decide on your room administrators,  grant them permission, and allow the room to receive requests but NOT allow direct booking.  (You and also play with Book-in and Request-In policies starting with this old but good Technet Article....this is beyond the scope of our post, though.)

Example: Allow Russ Iuliano to manage Auditorium meeting requests. 

Set-CalendarProcessing Auditorium -AllBookInPolicy $false -AllRequestInPolicy $true -ResourceDelegates "Russ Iuliano"

3. Grant administrators permission to send on behalf of the room.

From time to time, you may not
Example, Grant delegate "riuliano" send as permissions on behalf of Room CR 101B
Add-ADPermission cr_101b -Trustee riuliano@sumatra.com -AccessRights "Send As"

Finally, You can read more about creating and managing room booking on Microsoft Technet.

Which version of Exchange should you be on for a calendar migration?

For a Sumatra calendar migration you should be on the latest update to Exchange (currently Cumulative Update 9).

At the very least, CU6, owing to that fixing problems with Contact Notes.

We spent an hour last week diagnosing problems with Exchange 2013 CU 4 -- once the Exchange environment was updated the issues went away.

Manifesto for Calendar Server Migration

What are the current gaps in calendaring migration?

Calendaring is fundamentally different from email even though it usually uses it as a transport protocol.

Historically all migration solutions have focused on email.  Not surprising since email is a mission-critical concern.

But where email is static once you have sent or received it, calendars have a crucial difference:  they contain evolving meetings that are linked to the calendars of other individuals in the enterprise.  In Exchange changing a meeting updates the calendars of attending resources and individuals.

And in a real migration you need to take these links and the data associated with them along or you’re only doing part of the job.

Nobody except Sumatra Development does this for calendaring.

Solutions other than Sumatra's treat calendars exactly like email:  they create the events but do NOT recreate live meetings because they ignore the guest lists, responses, recurrence patterns and resource  bookings.

Think if it like this: they take a print-out of a calendar and migrate that. We call this a “flat” migration. Most do not even take recurrence patterns. 

Sumatra re-creates the state, creating live meetings with guest lists (which you might have to map to new domains or addresses), responses, recurrence patterns, exceptions, and resource bookings.

We call this “full-state.”

Even in the on-premises Exchange to Office 365 world, Microsoft focuses on email and does not even offer a calendar migration path.  So we went out and blazed our own full-state migration method.

For small sites this is a tractable (if unpleasant) problem. It's still a productivity loss, but we’re talking a couple of hundred users.

For sites of 500 or more users the productivity hit can be immense.

Put another way:  after a full-state Sumatra migration the user and resource calendar data experience a seamless transition:  as though the enterprise had been using their new calendaring system all along.  With other solutions users actually need to find and recreate their meetings to make them live and update-able.

Finally, other solutions willfully ignore the possibility of failure.

We have an UNDO strategy to gracefully remove only the data we put in in in the event of catastrophe.  (We have seen servers fail in the middle of migration).

This is of course an overview from jet plane altitude and by the time we get through the first test phase with a client we’ve brought them to tree-top level.

Our web site: http://www.sumatra.com

It shows how our migrations work, and it also highlights some of the things
we’ve done in calendaring.

In a nutshell: if it involved MS Exchange calendaring / scheduling we can do it.

On-premises @MSFTExchange Migration to #Office365

A PowerPoint Presentation about migrating from on-premises Exchange to Office 365.

The Migration section does not specifically call out calendar migration -- but that's what we specialize in.



Towards the end the notion of a back-out plan is one of the main things we constantly harp on.  Our calendar migration can take Exchange to Office 365 preserving guest lists, responses, and recurrence patterns, and do it in BOTH directions and it includes an UNDO to selectively remove only the data inserted.

Microsoft Exchange Virtual Machines and your Calendar Migration Test Environment

These days everybody's doing migration testing in their virtual environments.  That's cool with us.

You should start your project by reading Best Practices for Virtualizing and Managing Exchange 2013.  It's a little dense and abstract.

But we also have a few Cliff's Notes (which is a trademark of somebody other than us which we use here metaphorically) to put in front of you for the calendar migration you are testing:

• Space consumption is a constant battle. To sway the odds in your favor we recommend:
• Circular logging  
• Remove log files (e.g., IIS, EWS) often,  
• Check event logs (or setup to overwrite)
• DNS vs Firewall. You want to get mail to flow locally, but not leave the testing sandbox.  This is always tricky and you should make sure you've got it right before you go to any appreciable scale with your testing.
• Keep your Active Directory on a separate Virtual Machine from your Exchange components.  Why?
• The Exchange VM already has enough to do – don’t add another function to its workload
• Next, a separate VM for AD should mimic your production architecture. It allows different administrators to manage discrete roles. You might as well start by following best practices.

Keep in mind, these are guidelines for your testing phase to make sure you do not run out of space in defined and constrained virtual environments.  You will want to adopt other behavior when you move to production.

Further good reading:

• Exchange 2013 diagnostic and performance log files

Move mailboxes between on-premises and Exchange Online organizations in 2013 hybrid deployments

Folks,

Do any of you have field experience with:

Move mailboxes between on-premises and Exchange Online organizations in 2013 hybrid deployments

?

We'd really be interested in the field stories of SPEED, RELIABILITY, and ISSUES.

You do not need to identify yourselves or even put it in the comments, we'd appreciate your confidential experiences via our contact page.

Closely related to this is Single sign-on with hybrid deployments.

Mapping Resource Names in Oracle Calendar Server to Microsoft Exchange Migration.

In Oracle Calendar Server, resources are database objects.

In Microsoft Exchange they are SMTP addresses with calendars.

So, while your export file names for Users should match the target SMTP address. the resource mapping file will actually map the ICS file name to the SMTP address.

For example, the export file:

             erp conference room 1 tiger.ics  

gets mapped to cr_colonial_222@YOURDOMAIN.COM

Here:

Side note: If you have parentheses in your Oracle Calendar Server resource name, for example:

                     ERP Conference Room 1 (Tiger)

Drop the parentheses or other nin-permitted characters and use the same mapping.

You will get results like this:

I.e., you will have the mapped resource as an Attendee, and the old resource name as the location (because in the source data it's just a text string we insert).

Follow-up to #CalDAV to #MSFTExchange calendar migration tool - round 2

If you have read #CalDAV to #MSFTExchange calendar migration tool - round 2 and said "all very well and good, but I want to LEAVE Microsoft Exchange for some other calendar server" -- WE CAN DO THAT.

We  can already read calendar data directly from the Exchange server and insert it full-state into another Exchange Server or Office 365, as you see here:

Taking all the data out of the source is (for us) simple, inserting it into another target is certainly within our expertise.

If you have at least 1000 users or a realistic budget we can discuss this.

#CalDAV to #MSFTExchange calendar migration tool - round 2

It's been almost exactly a year since we did a sanity check on this #CalDAV to #MSExchange calendar migration tool.

Since then we've field-proven full-state migration of Oracle Calendar Server to Exchange using ICS files -- which means we could insert ICS FULL-STATE for any of the other iCalendar standards based calendars.  You know -- Zimbra, Apple, Google being the only ones that matter these days.

Let us know if you have more than 500 users and want to give it a spin.

Speeding an Oracle Calendar to #MSFTExchange Migration by Parallel Insertions

If you have more than a few hundred users, you can run multiple instances of the Oracle Calendar Server to Microsoft Exchange migration code.

Let's say you have 1000 users and want to break it down by half.  Say from A to M and N through Z.  You can set up two separate instances as follows:

Who "Blank" to M?  Because numbers sort BEFORE "A" so things beginning with numbers are lost if you do not do "Blank" as your start.

Then "N" to "Z":

Just to be safe I'd run each of these on separate machines, but you use the SAME mapping tables for each.

Make sense?

Oh -- and if you want to insert just ONE calendar to test, this is the way to do it:

Put the same name in each endpoint box.

And this is an Oracle Calendar to Office 365 migration in action:

Oracle Calendar Designate to #MSFTExchange Delegate Rights Migration

We at Sumatra are no strangers to the issues of delegate/proxy/designate migration into Microsoft Exchange 2013 / Office 365.

We just refuse to do it ourselves anymore.

Why?  Because while we can give you the best possible technical solution, it is not always the best social or political solution for a given environment.  Someone's gonna grumble.  And we do not need that.

If YOU on the other hand can manage your organization sufficiently well for your purposes, we're fine with it.

Here's what you do.

Let's start at the back, where we insert calendar delegate rights into Exchange.

You need the command Add-MailboxFolderPermission in PowerShell.

This format which can be executed in PowerShell to set calendar permissions on Exchange. as we do here:  

Which means in Outlook looking at an Exchange server the user will see this in Calendar Properties:

So working backwards, you need to get Designate permissions on the Oracle Calendar Server side.

Say you need to get Designate rights for Russ Iuliano from OCS:

uniaccessrights -ls -grantor %1 -grantee "S=Iuliano/G=Russ" -n 1 -p PASSWORD >>russ_rights.txt

The output of UNIACCESSRIGHTS is relatively straight-forward to read:

"S=Iuliano/G=Russ" Grantee: S=Iuliano/G=Russ/UID=riuliano/ID=257/NODE-ID=1 Designate Right: CONFIDENTIALEVENT=VIEWTIME/CONFIDENTIALTASK=MODIFY/NORMALEVENT= MODIFY/NORMALTASK=MODIFY/PERSONALEVENT=REPLY/PERSONALTASK= MODIFY/PUBLICEVENT=NONE/PUBLICTASK=MODIFYEvent Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALL Grantee: S=Whiplash/G=Snidely/UID=swhiplash/ID=260/NODE-ID=1Event Viewing Right: CONFIDENTIAL=NONE/NORMAL=ALL/PERSONAL=TIME

Depending on how you implement your OCS Delegate to Microsoft Exchange Mapping you need to parse the UNIACCESSRIGHTS output into this format which can be read in PowerShell to set calendar permissions on Exchange.

You need to execute this from PowerShell.  Needless to say this command should be called something like russ_rights.ps to execute in PowerShell. 

To launch PowerShell: Start > All Programs > Accessories > Windows PowerShell > Windows PowerShell right-hand click and "Run-As administrator"

The parser we'll leave to you and write about in a future blog post.