Migrating Resource Scheduler Data into Exchange 2007

No sooner was one of us back from the Seattle Opera Ring Cycle (Janice Baird rocks!) than we got one of our favorite types of inquiries: Can we get data out of Resource Scheduler and into Exchange 2007 native?

Short answer: Yes.


If you're primarily using Resource Scheduler to book rooms (something Exchange 2003 did not do well) and want to take advantage of the newer (and better) capability in Exchange 2007, this is very doable. We've already figured out how the Resource Scheduler SQL schema is structured and can simply modify and re-propose the meetings with mailbox-enabled resources on E2K7. With this knowledge if you want to try to write this code yourselves, go ahead, but be forewarned, it is harder than you think.


In contrast to the hundreds of calendar migrations we've done, this is more of an informed consent clinical trial right now, but if you're interested drop us a line. The more interest there is the more likely it is we'll proceed with development.


You should also read: Resource scheduling in Exchange Server 2007 and Using Exchange 2007 for Resource Booking. For the truly adventurous and technically adept, check out How to Create or Remove Custom Resource Properties.

Resource Scheduler for Outlook/Exchange migration flow

These go through the flow process for how we migrate data from PeopleCube Resource Scheduler for Outlook/Exchange into Exchange 2007.

This is an excellent overview of scheduling resources in Exchange 2007.

Phase I: Resources scheduled via Outlook



Resource accounts MUST:

• Exist and be mail-enabled in Exchange 2007 and Active Directory


• Be configured to process meeting requests


• Client (that's you) must provide a map between RSOE resource name and Exchange Resource alias/email address
  

Testing and Use:

Service Account defined with impersonate + send-as permissions

• Test this in a lab prior to running in production


• Sumatra code will run on a 32-bit machine (NOT on a 64-bit server)


• Code will use Exchange Web Services through an Exchange 2007 CAS


• End Users use Outlook 2007


• Meeting updates:
  a) Accepted as part of Exchange 2007 features,
  b) might remain in all end user’ inbox post-update and will not be removed


• The Sumatra process:
  a) will not check for resource double-booking or conflicts
  b) will work on CURRENT meetings only – it will skip expired/completed meetings as determined by RSOE’s meeting end date
  c) will not configure Exchange resources with settings to ensure resource will behave as RSOE resources (i.e., you control the process by provisioning your resources as you want beforehand)
  d) Responses from Exchange’s Resource management will remain in the meeting organizer’s inbox
  e) Note: Outlook-booked meetings are defined as those meetings, found in the user’s Exchange "Calendar" folder, that have an "RSOE" meeting tag (The tag is attached to the meeting as a hidden MAPI code.)

Phase 2: Scheduled via the Web

PROCESS ASSUMPTIONS:
See assumptions from Phase 1.
Phase 2 should be run after phase 1 completes
The Sumatra process:

• Creates a meeting with the name "RSOE_Migrated" in the organizer’s calendar. The meeting with have the resource as the only "attendee". All Direct-booked meetings will be created as one-time meetings.
• Does not check for double-booking or conflicts (That's what Exchange is for).
  For the resource: If a conflict exists, Exchange will decline the meeting request
  For the meeting organizer: A "double booked" meeting will be added to the end-user’s calendar
• Works on CURRENT meetings only – it skips expired/completed meetings as determined by RSOE’s meeting end date
• Does not attempt to link or match this meeting to an existing meeting in the
  organizer’s calendar
• Note: direct-booked meetings are defined as those meetings in booked in RSOE that do not have an outlook "RSOE" tag.
• Responses from Exchange’s Resource management will remain in the meeting organizer’s inbox
• Meeting times are recorded in RSOE as the server’s "local" time, and will be added to the meeting organizer’s calendar in the "local" time and time zone (even if the meeting organizer is in a different time zone.)

Exchange 2007 Permissions

In Exchange 2003 permissions were by far the biggest headache for folks wanting to migrate.

Exchange 2007 is shaping up to be a bigger headache. Think migraine. Think migraine with sinusitis. Then double it. You know what I mean. We have had to create an entire Label for permissions.

However, we would really like to thank Rohit from Extreme Networks for coming up with the following variation on setting permissions.

He was looking to migrate Resource Scheduler, but it's just as viable for general calendar migrations.

If you're using Ex2007 as the service account to run our code, execute this command:

Get-OrganizationConfig Add-AdPermission -user ex2007 -accessRights GenericAll -extendedrights "Receive as","Send as", "ms-Exch-EPI-May-Impersonate", "ms-Exch-EPI-Impersonation" -InheritanceType All

Takes care of all necessary permissions with one swoop.

(Note: Revised 2/15/2008 -- a pipe ("") should be place between get-organizationconfig and add-adpermission. It was stripped when pasting the command line in this blog)

Update 11/11/2010:

1) Added '-InheritanceType All' to the commandlet. Sometimes permission inheritance issues prevent access to calendars.

2) Remember that RESOURCE accounts must be ENABLED (via ADU&C)

3) If you want to look at calendars via OWA, you need fullaccess. This commandlet grants 'exsu' full access to all accounts in the domain:

Get-Mailbox -resultsize unlimited add-mailboxpermission -user exsu -accessrights: fullaccess -InheritanceType: All
--Russ

Migrating RSOE (Resource Scheduler for Exchange) data into Exchange 2007

A few months ago we got asked if we could extract data out of Resource Scheduler for Exchange (RSOE) from PeopleCube and insert it into Exchange 2007.


Well, because of a request from the West Coast we went ahead and did it. They mainly use RSOE for straight-forward room reservations and are looking to simply transition to the resource reservation features in Exchange 2007. So all we're interested in is moving the reservations in as few steps as possible into Exchange. We make no effort to recreate most of the other features of RSOE (prep time, cleanup times, etc.), all we're doing is transitioning the resource management over.

Here's how it works.

There are two ways to reserve a resource in RSOE:

• Via a from in Outlook
• Directly from a web browser

So we deal with each of these cases differently.

From Outlook

This is the easy case. Resource Scheduler puts a MAPI flag and an RSOE identification number in the meeting.

Technical background: Those of you who know how to use OutlookSpy (an invaluable tool for the Exchange developer) can look for RSOCEntryID.

We read this from the RSOE SQL database into an Access database and (since we know the meeting organizer and can uniquely identify the meeting via the MAPI tag), we add the E2K7 resource to the meeting and update it.

The code relies on Outlook 2007/Exchange 2007 to automatically apply meeting updates if an end user has already accepted that meeting. e.g. a time or location change to the meeting is received, the meeting will be automatically updated and the old invitation marked out of date so users will not accidentally accept it. See the TechNet article:
http://www.microsoft.com/technet/technetmag/issues/2006/12/outlook/default.aspx

DONE.

From the Web

This is a more interesting case and we took the most general way of solving it.

Since there is no unambiguous link between the meeting reservation in RSOE and any existing data in Outlook (and a quick look at real world data will convince you that just being at the same time and date is not enough), we just create one meeting owned by the resource owner, with the resource in E2K7.

E2K7 books it and then the meeting organizer can add users or modify as they see fit.

PROCESS ASSUMPTIONS

1. Resource accounts MUST:
   a) exist and be mail-enabled in Exchange 2007, Active Directory
   b) be configured to process meeting requests
   c) Client must provide a map between RSOE resource name and Exchange Resource alias/email address


2. Testing and Use:
   a) Service Account defined with Impersonate and Send-As permissions
   b) Test in a lab prior to running in production!!
   c) Sumatra code runs on a 32-bit machine (NOT on a 64-bit Exchange server)
   d) Code uses Exchange Web Services through an Exchange 2007 CAS


3. End Users use Outlook 2007


4. Meeting updates:
   a) accepted as part of Exchange 2007 features,
   b) might remain in all end user’ inbox post-update and will not be removed by our code (up to the end user).


5. The Sumatra process:
   a) does not check for resource double-booking or conflicts
   b) works on CURRENT meetings only – it will skip expired/completed meetings as determined by RSOE’s meeting end date

Migrating Data from Resource Scheduler to Exchange 2007 Resources

A typical week here at Sumatra involved at least one request to take data from one system we've never seen before and put it into one we know (or vice-versa).

A few weeks ago it involved a request to migrate data from Resource Scheduler for Exchange from PeopleCube.


The idea was that they wanted to start using the native room and resource scheduling capability in Exchange 2007 instead additional software.


This presents some interesting problems.

Before we coded anything, we thought we'd ask our reading public if there was anyone else out there who wanted to migrate Resource Scheduler data, because it's only worth doing this if there's more than one site.