Tuesday, October 25, 2011

More Schema Fun

So let's say you don't have any sort of Exchange on premises for an Office 365 deployment.  You have Active Directory on premises for authentication and some local storage for things like QuickBooks or large volumes of CAD drawings.  Office 365 seems like a good fit for a small organization because you just don't need those extra servers and management overhead.

Wait, wait! Don't tell me!

But once again, schema matters, because when you created a new user, even though you set their eUPN accordingly, they're getting email aliases with that pesky onmicrosoft.com domain as the primary alias.  So you think, It's just Exchange 2010, I'll use PowerShell remoting and do some wizardry behind the scenes.  Nope, fail.  You can't.  The primary SMTP alias comes from an Active Directory property that's automatically populated in domains with on premises Exchange when you create a user's mailbox.

Enter the ADSIEdit

If you've been an Exchange administrator for a while, you've probably played with the proxyAddresses attribute before.  I've mentioned it before when you're looking to add a secondary alias.  But if you don't even have a primary alias, you'll be seeing this:

proxyAddresses is undefined

Launching ADSIEdit from Administrator Tools on the Start Menu gets us going.  Connect to your Default Naming Context and drill down to your user object.  Right clicking the user allows you to select Properties.  Double check that the Show only attributes that have values is unchecked.

Drilling down through our list you'll see that proxyAddresses is blank.  Set it to SMTP:youralias@vanitydomain.com.  Make sure that you have one and only one address with the SMTP capitalized.  Hop over to your Directory Synchronization host and re-run the Directory Synchronization Configuration wizard.

Other Cool Stuff

Let's say you want to see who you've missed this property on before.  If you launch ADUC, you can create a custom query and configure an LDAP filter:


Thursday, October 20, 2011

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.