Featured Post

How the Sumatra Double-Booking cmdlet works

First: you can always get help at the PowerShell prompt with: get-help Get-suDoubleBookedMeetings Let's say that we have the followin...

Tuesday, July 07, 2015

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.

No comments: