Office 365: Schema Matters

We just pushed an a la carte deployment of Microsoft Online services in order to eliminate the on-premises requirements for Lync.  In the process, we discovered that our legacy OCS 2007 internal-only deployment caused some schema issues for us.  We had politely decommissioned the OCS host by un-registering the various roles, uninstalling the application, then eventually disjoining it from the domain.

The evils of directory synchronization

But this environment is running ADFS2 and DirSync for a unified single sign-on experience.  That means any AD schema extensions we have regarding Exchange or Lync/OCS are propagated to the cloud.  The most critical property is msRTCSIP-UserEnabled.  Anyone who logged into OCS in the legacy deployment has this attribute, and during the above decommissioning procedures, it is set to FALSE by the installers.  Give it 3 hours, and now you have licensed users in Office 365, who have AD properties to the contrary.  But you can't change it from the cloud, you have to change it in your AD and force a synchronization.

Don't let this happen to you.

ADModify.net to the rescue

Enter my favorite ADDS tool (and soon to be yours), ADModify.net.  This tool uses LDAP calls to ADDS, scripting mass changes behind the scenes.  This is useful not only for resolving this problem, but also for setting your eUPN to your vanity domain for all desired Office 365 users.  It's also a portable app you can keep on a USB drive for quickly making changes at customer sites.

Before we solve our problem, don't forget to add %sAMAccountName% in the Legacy Account field of the Account tab, or you'll blank out everyone's UPNs!  It's simple to resolve, but easy to miss.

Set that eUPN, but don't forget %sAMAccountName%

Moving on to the Custom tab, check the Make a customized attribute modification and specify our troublesome property, msRTCSIP-UserEnabled, and set it to TRUE.  Note, this will add the property to any objects that currently do not have it, so select users judiciously.

Set a custom attribute, for everyone.

Hit Go! then jump on your DirSync server and force a synchronization and it's off to the races for Lync.

Why do I care?

You probably asking why this even matters.  Well, with DirSync, if you have a property Microsoft cares about (pretty much from any co-existence scenario), then Microsoft is going to take that objects property and put it in their AD.  Say you're in an organization that never had on-premises Exchange and you move to Office 365.  Well that means with SSO and DirSync, you won't be able to set the msExchangeHideFromAddressLists property, because your schema doesn't have it.  And you can't make that change via remote PowerShell or the Exchange Online console because Microsoft expects it to come from your on-premises AD.

So, know your limits.  And also know your recent schema changes and how to look for differences between objects.