Converting Mailboxes to Mail-Users with ILM for Exchange 2003 AD

After couple of weeks of working with a client of mine in Boston area, I’ve learn more about Exchange 2003 than I care to learn, and wanted to share some snippets of information with my fellow-Outlookers.

Using ILM as a migration tool

First of all, I have to say that, for better or for worse, proverb "if all you have is a hammer, everything looks like a nail" applies very nicely to the method I am about to describe. In short, I have managed to set-up ILM server for the tasks that are traditionally done with other tools (mostly scripts). I cannot advocate this usage of the product, nevertheless if you are "fluent" with ILM you will find that this method have its advantages over any kind of script.
Firstly, ILM will provide you with staged environment. Any bulk operation that script would perform directly on your AD, ILM would stage and allow you to have a chance to analyze pending exports before actually committing changes to the directory. Secondary you will get to use managed code vs. script language, which is a better choice, in my honest opinion.
On the flip side, setting-up ILM just to perform migration process is an overkill. Not only you’ll need to install Windows Server, SQL Server, ILM Server, OL Sync with all dependencies and apply all Service Packs, you also need to install Visual Studio. All that takes time; if you don’t have that time (or desire to install all this stuff) you might want to consider using scripts which are not require any "infrastructure".

So what do we need to do?

In the scenario when school converting their student mailboxes from on-premise AD with on-premise Exchange 2003 to hosted Outlook Live solution, and intending to use OL Sync (GAL Sync) you will need to figure out how to convert existing student user accounts with mailboxes to mail-enabled users… in bulk. Reason being for this requirement is an OL Sync "rule". Outlook Live Sync will automatically create mailboxes in the cloud, based on your Active Directory information. Every mail-enabled user (an Active Directory user object with mailAlias and targetAddress populated) will receive corresponding mailbox in the cloud. However user with mailbox on-premise will NOT have a mailbox created in the cloud (which is understandable; there is no reason to have two mailboxes)
It is all sounding simple enough, until you are looking into details of such operation. How do we exactly going to convert thousands of users with mailboxes to mail-enabled-users?
Let’s flashback to year 2003… Exchange 2003 fully relied on AD to provide "key" attributes that will identify a user object as a mailbox-deserving or mail-enabled-user object. UI of Active Directory Users and Computers was taking care of all of those operations by simply pre-setting some attribute values in AD; in turn, Exchange 2003 would "sense" those values and act accordingly to create a mailbox or append mail-enabled user to its GAL. There were NO direct calls to Exchange server form the snap-in itself (to my knowledge). As it turns, all we need to do, it to figure out which attributes are responsible for identification of mailbox vs. mail-user and "voila" — we have got ourselves a conversion machine.
 

Outlook Cash

There is another thing to remember. Prior to migration, teaching staff could have emailed to a student from their Outlook. That operation was performed as from on-premise to on-premise email operation. After migration is done, should a teacher use Outlook to email to the same student again, he/she would likely to use "auto-complete" feature that will pick previously resolved address for a student, which would be incorrect, since on-premise mailbox for that particular user is no longer present in on-premise Exchange. It was replaced with mail-enabled user object; As a result, message will bounce back and teacher will likely to make a phone call to tech support.
Boston colleagues of mine, did not fancy the idea of talking with their teaches all that much, so we had to figure out how to solve this dilemma during migration.
 

So what did we actually do?

Outside of running IMAP mail-content migration process and providing password synchronization between on-premise and the cloud (Outlook Live) environment for all new and existing users and figuring-out email flow during split-namespace scenario, we had to figure out how to convert existing users with mailboxes (MBX) to mail-enabled-users (MEU).

Deleting attributes:

As I have mentioned before several attributes in AD are responsible to "linking" mailbox in Exchange 2003 mail-store with an actual user account. Delete or modify those attributes and Exchange mailbox will lose its "connection" to the user in AD. Augment some user attributes and Exchange 2003 will identify that user account as a mail-enabled user object, which will be displayed in local GAL (visible to all teaching staff, which will keep mailboxes on-premise)
So what are those magic attributes?
Before somebody in Exchange team or Microsoft legal team gives me a call and kills me, I want to say that if you are about to perform this operation – you are doing it at your own risk. I (or anybody else to my knowledge) cannot guarantee that this will work for you. So please test and do plenty of backups before editing your production directory.

To "sever" user form his/her on-premise mailbox I’ve deleted values in following attributes form every student account:
homeMTA; homeMDB; mDBUseDefaults; mail; msExchHomeServerName; msExchMailboxSecurityDescriptor; msExchMailboxGuid; msExchALObjectVersion
To mark user as a "mail-enabled-user":
I’ve set value of Windows Live ID for each particular user to "targetAddress" attribute and to "mail" attribute
I’ve set "mailNickname" attribute value to be user’s ‘left’ side of the Windows Live ID value (to the left form @ sign)
I’ve set value of "false" to "iMAPIRecepient" attribute (this was optional)
To address "Outlook Cash" issue (see above):
I’ve stored value of "legacyExchangeDN" and added that value with a prefix of "X500:" as one of the entries in "proxyAddresses" attribute.

Conclusion

All that was performed with ILM 2007 with a single Active directory Management Agent configured to import and export mentioned-above attributes, and rather simplistic extension code that ensured formatting attributes.
It took several days to go through procedures and meetings, however in the end we have had clean conversion and good tractability – thanks to ILM logs with every operation on every object being captured.
ILM provided nice platform for reviewing upcoming changes on user objects as well as a way of communicating with AD
Advertisements
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: