Exchange 2010 SP1 Managed API 1.1 released

For the last two weeks I've been puzzled why the installation of the EWS Managed API SDK v1.1 does not install the API library. Turns out it was released today (two weeks after the SDK was released.) Click here for the link to the release blog posting or to the download page.

Exchange 2010 Mapping Users - A Brief Guide

Compared to taking data from a legacy system and putting it into Exchange, you'd think user mapping between the two systems would be pretty easy. Usually it is straight-forward, just incredibly tedious and time-consuming (the occasional input error does not help much).

This is a brief guide to user mapping.

Let's say we have three users with the following addresses on Oracle Calendar Server and Exchange:

We design the process so that by the time you've created your intermediate database you should already have the email addresses for these users in the Users table.

So the brief rules are:

• Do NOTHING for OCS email addresses that are the same as in Exchange
• Add entries to the User_Adjusted_Maps table to map OCS accounts that have different Exhcange addresses
• Run the following queries Q_Build_CustIDs_From_MMUserids, Q_Build_CustIDs_AdjustMMUsersids, Q_1_Make_User_Map, FInd duplicates for MM_Exchange_User_Map
• Look at the results in MM_Exchange_User_Map
• Repeat until all of your accounts are done.

The mapping table will look like this when you're done.

A few other things to keep in mind.
If Oracle Calendar Server IDs are THE SAME as Exchange:

• Make sure the Primary SMTP or UPN is defined as login@mydomain.com

If Oracle Calendar Server IDs are DIFFERENT from Exchange:

• MAP the differences (Tables)
• Build the mapping table
• Overlay the changes

Once you've got all your users mapped you can just edit the mapping table. But please exercise proper handling and care with it. You do not want to be wondering which version to use when starting yoru migration at midnight on a Friday.

UNICPOUTU unreliable in some Oracle Calendar Environments

Let us let you in on one of the open secrets of calendar migration: It's not a wise investment to put a lot of code into pulling data OUT of a legacy system. Better to use one of the utilities the legacy system uses for purposes of upgrading servers or moving users between servers. Less prone to error, it uses the legacy's capability against itself, and it allows a migrator to put their effort into getting the data INTO the target system.

Sometimes though this gets more difficult when there's bugs in the legacy system.
One of our clients (shout out to Matt in North Carolina!), discovered some data missing from the UNICPOUTU export in their Solaris environment.

Quel horreur!

It's been mentioned a little on the OCS boards, but nobody is making a big deal about it and it is unlikely Oracle is going to fix it to make breaking your OCS habit any easier.

Thus far we've seen this ONLY with OCS 10.x on Solaris (all the 9.0.4 migration systems look absolutely peachy and we've been doing 10.x for years with no issues). We suspect it's with the very latest and is more prone to happen when the export is constrained by date (so export everything and let us segment it in our tools).

So as always, keep an eye out.

Putting Holidays into Live @ Edu Server-Side

We tested our holiday insertion code on Live @ Edu and a list of holidays like this:






Note that this is an All Day Event (and you can specify if the time is to be shown BUSY or FREE):

While this is an appointment we've put into every calendar without any muss or fuss. You could use the same technology to do that for anything else you want (Shareholder's Meetings, Fire Drills, as your business and imagination dictate).

Any of you who have been through a migration with us know why we keep the "(Migrated)" tags, but you can decide to not use them.
This is scriptable so you can create holidays as you provision users if you have an automated system for so doing.


A few other things to keep in mind:

• This runs as an EWS application from a 32-bit workstation. So all your credentials are completely under your control. If there's demand to run this as an online service we'll listen.


• We take the default time zone of your server for all insertions. If you have users in multiple time zones and want to do this contact us -- that would be a different version.


• You can specify a single user, a list of users, or an LDAP query to handle your insertion.

Handling Conference Rooms in a migration into Exchange

Resources are kind of a pain in the neck in a migration. You want them to take care of themselves when you're done migrating. But to get your data from your old system into your new system with the same state, you're going to need to treat them with kid gloves and lots of TLC.

So we have the following guidelines:

Put all resources in one or more OUs for ease of administration.
PRIOR to migration:

• ENABLE all of the resource accounts via Active Directory Users and Computers
• HIDE the accounts from the GAL
• Configure resources NOT to AutoAccept meetings

AFTER the migration

• Disable the accounts and add them to the GAL
• Configure the resource for AutoAccept (if you desire first-come-first-served functionality) or
• Use group-policy settings for managed rooms and resources

Exchange 2010 Permissions for Migration

Impersonation has nothing to do with Frank Gorshin or Rich Little.
It's the permission you need to give your service account to execute a full-state calendar migration.

Create a managementRoleAssignment:

new-ManagementRoleAssignment

-Name:_suImp8

-Role:ApplicationImpersonation

-User:'mysvcaccount@mydomain.com'

If you have to ask where you're doing this, please go to your Exchange Administrator.