Implementing Exchange Online with an existing on-premises identity management solution that provisions mailboxes

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.  Smile

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:

  1. 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.)
  2. 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:

  1. A mail-object is provisioned or finalised.
  2. A mail-object is made consistent and EAP applied.
  3. 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…


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, FIM 2010 R2, Office 365 and tagged , , , , , , , . Bookmark the permalink.

6 Responses to Implementing Exchange Online with an existing on-premises identity management solution that provisions mailboxes

  1. Scott Eastin says:

    Good post and thanks for the heads up. Sounds like you need a beer!

  2. Paul – why don’t you take all the Exchange nastiness out-of-band in a post process PowerShell step (which I tend to do in other scenarios, not specifically yours) where you have more control over the logic, albeit at the slight expense of making it a little more challenging to identify the object you’re changing which actually does require a cmdlet to run? In the simplest provisioning scenario the post-export script simply searches for users in your target AD with those attributes set but without a mailbox and creates one. In your scenario, however, I take it you can’t go searching in a generic sense for these objects … you need to know them explicitly right? In that case, I plan to use an audit drop file from the AD export, run a transform over it to pull out the PowerShell cmdlet parameters I need, then run a script for each one. Can you see any problem with that approach?

    • I like the drop file idea. In a workshop yesterday my options, in order of preference, were:

      1. ECMA (probably using the PowerShell connector to be honest)
      2. Post export script, i.e. invoked by the synchronisation script when the cycle ends
      3. Daily (nightly) script

      I don’t really like 3 as this is a pretty large environment. Your idea improves the efficiency of #2 considerably.

      I’m still going to push for #1, as I need to handle not just the migration fun – which will probably last around 18 months – but also the end state of all new mailboxes being provisioned in EXO. The ADMA can’t handle that provisioning operation today and the roadmap gives me no clues that Update-Recipient and/or the ADMA will be updated to support this scenario.

      My worry is the additional complexity added to an already complex topology (FIM Service and Portal (three farms :), SSPR, Reporting, ILM-style sync engine design, upstream self-service capabilities into three authoritative sources). Then again, we have no choice…

      What is frustrating is the lack of adequate support for Exchange. I’d really like to see a more joined up, out-of-box way of provisioning and deprovisioning mailboxes and transitioning between states. It’s a pain having to write custom connectors to support archiving and deprovisioning for one of Microsoft’s most widely adopted products.

      • Agreed it should be OOTB Paul – for the reasons you say. However it was Carol who told me I had rocks in my head ever turning the ADDS MA’s Exchange integration feature on at all some time back and have never done ever since. Figure that it’s the same argument as with declarative sync rules – unless you can cover 100% of the EAF/IAF use cases in your SR and not complement them with the ILM ones as you call them, then make them all ILM EAF/IAFs. Same here really with the post process. Actually the PSMA sounds better than the drop file if you keep the ADDS MA with the exchange switch off too – both would do the same thing but the PSMA might give better transparency. Tell me how you go here?

  3. Pingback: (2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365 « Jorge's Quest For Knowledge!

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s