I’m going to start this post with a bold statement. Implementing Exchange Hybrid in an enterprise environment that has an existing on-premises identity management (IdM) capability that provisions on-premises mailboxes is not easy. Especially when that on-premises IdM solution is Forefront Identity Manager (FIM) or Identity Lifecycle Manager (ILM, or even MIIS).
I’m particularly fond of FIM. Not just because I pretty much earn my living knowing how it works where many do not. I like it’s simplicity. It’s binary outlook and view of the wider enterprise. In short, the state-based nature of synchronisation. It’s awesome. And it’s also a massive pain in the ass!
When I say simplicity and binary above I don’t mean the product is simple – it is not in anyway simple. I’m lovingly referring to the state-based logic that, in layman’s terms, goes like this:
According to the holograms for the <insert managed identity system name here> connector the value for attribute <some relevant name goes here> is NULL (i.e. it is not set or it has been deleted) therefore this new value imported is WRONG and will be deleted.
See what I mean? Simple. Is the value correct? No. Then make it correct. Binary.
Now, as I’m sure I’ve said before the state-based nature is powerful and provides great flexibility, particularly from a the perspective of retrying failed operations. It is also problematic when you require a degree of multi-mastery. I don’t want to get into the debate of precedence and how equality of precedence is evil here. I just want to pound some keys and vent some basic frustration at how much fun you might have ahead of you if you have FIM provisioning mailboxes on-premises using the out-of-box Active Directory Domain Services Management Agent (ADMA) and you start moving mailboxes to Exchange Online.
The migration to Exchange Online, simplistically, goes as follows:
- Stage – Replicate 95% of mailbox data into a new mailbox database in the cloud.
- Migrate – Replicate the remaining 5% of data and mark the cloud mailbox database online and the on-premises database offline, or migrated.
- Finalise – Modify Exchange-owned attribute values to reflect the fact that this mailbox is now hosted in Exchange Online, i.e. mark the mailbox as a remote mailbox.
The last part is the interesting part to IdM folk. The transition from mailbox into remote mailbox. From the perspective of the provisioning engine (FIM SYNC) a mailbox is a user (or inetOrgPerson) object with a mailNickname, homeMDB and msExchHomeServerName value. When an object is in this state FIM exports those values to AD using LDAP, just like any other attribute value, and then invokes the Update-Recipient cmdlet which itself does one of two things:
- Looks at the object type and attribute values and, if the object type is user and there are mailNickname, homeMDB and msExchHomeServerName values and the object is not a mailbox then mailbox-enable it, i.e. act as a simplistic wrapper around Enable-Mailbox. (This is but one example, it also “acts as a wrapper” around Enable-MailUser, Enable-MailContact and Enable-DistributionGroup, for example.)
- Invokes Email Address Policy (EAP). If the object (we’re talking mailboxes and will continue to do so) is in a valid state, i.e. it is a mailbox, then apply EAP and the corresponding attribute validation and updates that go with that process, i.e. maintain consistency.
I am simplifying this using known terms, not actually explaining how this works, but the principal is reasonably accurate. Every single export to an AD object made by the ADMA, including password set from SSPR or PCNS, results in Update-Recipient being invoked when Exchange provisioning is enabled. There’s no clever logic. Open an LDAP connection with AD, open a Remote PowerShell (RPS) connection with an Exchange Client Access Server (CAS), export change(s) to AD and invoke Update-Recipient. This means one of three things happens:
- A mail-object is provisioned or finalised.
- A mail-object is made consistent and EAP applied.
- Nothing happens because the object isn’t mail-enabled.
Why am I telling you all this? Because a remote mailbox looks an awful lot like a mail-user. In fact, from the perspective of FIM, which doesn’t care about values such as msExchRecipientDisplayType, msExchRecipientTypeDetails and msExchRemoteRecipientType a remote mailbox is basically a Mail-User.
As stated, a mailbox looks like this:
- Object type: user (or inetOrgPerson)
- Mandatory Exchange attributes: mailNickname, homeMDB and msExchHomeServerName (and not mandatory but generally toggled mDBUseDefaults)
A mail-user looks like this:
- Object type: user (or inetOrgPerson)
- Mandatory Exchange attributes: mailNickname, targetAddress
So, when you migrate a mailbox from on-premises Exchange 2010 or 2013 it loses its homeMDB and msExchHomeServerName values and gains a targetAddress value. Without factoring other Exchange-specific values this means, from the perspective of the FIM Synchronization tower that the object is a mail-user not a mailbox.
So what does FIM do? It deletes that targetAddress and adds the homeMDB and msExchHomeServerName values back to the connector, exports that delta to AD via LDAP modification, and invokes Update-Recipient. What does Update-Recipient do? It checks to see if the value is a mailbox, which it is not, and makes it one.
Oh right, what does that mean?
You now have a new mailbox on-premises that receives email instead of routing it up to Exchange Online. And every time you fix it, FIM comes along and un-fixes it.
State-based identity synchronisation. Powerful, simple, effective.
I’m glad I got that off my chest. I’m not saying the problem is insurmountable. It isn’t. But if the Office 365 programme or Exchange team are not very closely aligned with the IdM team (which they never are) then the Office 365 Exchange pilot is about to get delayed…