Exploring Outlook Live Synchronization
This posting is provided "AS IS" with no warranties, and confers no rights.
Recently I had a chance to work with Outlook Live Directory Synchronization tool. For those who don’t know, this tool allows to synchronize on premise AD objects with Microsoft’s cloud Exchange offering for education sector customers, also known as Live@EDU.
I found the documentation provided by Outlook Live team to be excellent, and I was able to get myself up and running very quickly. But along the way I noticed several interesting points, which could be worth mentioning; hence the intention of this blog entry is to provide some insight into the operations of this tool.
What configuration file?
OLMA Event 1031
Once I completed the configuration wizard I decided to run “full import (stage only)” and “full sync” on the OnPremise MA, since conceptually AD objects are first projected to Metaverse and then provisioned to the Hosted MA connector space. I admit that I did not finish reading the documentation to the end, which explicitly instructs to run the StartSync –FirstRun (StartSync is a PowerShell script provided as part of the solution), and the FirstRun switch exercises the MA run profiles in the right order to initialize the tool.
To my surprise I got this exception. The documentation did not mention any configuration files, so needless to say I was a bit puzzled.
Not being able to solve this problem I moved to the OnPremise MA, and ran “full import (stage only)” run profile. I had better luck with this MA and the run profile completed successfully. After this I decided to give my OnPremise MA another try and to my surprise the run profiles completed without errors.
So obviously, the Hosted MA does more during the import stage than simply bringing objects from the Outlook Live to the connector space. After doing further investigation, I found ConfigurationParameters.xml file, which contains various configuration parameters for the Outlook Live service. After doing further digging (OK, I admit I used a reflector to look at the code), I confirmed that this file is being referenced by the OnPremise MA, which explains the error, and that this file is created during the import run of the Hosted MA. Hence to initialize the system the Hosted MA needs to be run first, in order to create the configuration file.
We will come back to this configuration file, since it will help solving another puzzle.
AcceptedDomains and UserPrincipalName, what is the relationship?
Once the MAs were initialized I decided to add a test user and try provisioning it to Outlook Live. My test AD’s DNS name is contoso.com, and the test Outlook Live environment accepts mail for e14tap.com and proxy.e14tap.com. So I created a user the following parameters: userPrincipalName – dcuttler@contoso.com, mail – dcuttler@e14tap.com.
During the synchronization run I got this exception
My questions were:
What are accepted domains?
Since I did not configure this property anywhere, how does the Synchronization Service learn about them?
Logically enough, accepted domains are the SMTP domains for which Outlook Live accepts mail, so in my case they were e14tap.com and proxy.e14tap.com. This is configured in Outlook Live management console.
During an import run of the Hosted MA the accepted domains are written into ConfigurationParameters.xml.
Provisioning code queries ConfigurationParameters.xml to ensure the validity of the Windows Live ID, and if the proposed ID does not match any of the accepted domains, an exception is raised. The “MVWindowsLiveIdAttributeName” parameter determines which AD attribute is utilized to create Windows Live ID, by default userPrincipalName is used.
So to get pass this error, I added a new UPN suffix (e14tap.com) to my test AD and change the userPrincipalName of my test user to dcuttler@e14tap.com.
By the way, one can add a UPN suffix by using Active Directory Domains and Trusts snap-in.
Obviously a less intrusive approach, especially in a production environment, would be to modify the MVWindowsLiveIdAttributeName. In my case, I set MVWindowsLiveIdAttributeName to WindowsEmailAddress.
WindowsEmailAddress is the Metaverse attribute, which gets populated from the AD mail attribute.
More details on MVWindowsLiveIdAttributeName parameter can be found here.
Remember to run “import (stage only)” profile on the Hosted MA after changing MVWindowsLiveIdAttributeName value, since this is what will update ConfigurationParameters.xml.
This is a bit counter intuitive, since we would expect that the OnPremise MA (AD) should gather all of its information either from the connected system or from its own configuration. This is the peculiarity of this solution where ConfigurationParameters.xml is generated by the Hosted MA, but is referenced by the OnPremise MA.
Expect renames on delta import after exporting adds
Outlook Live is one of those systems which create unique IDs (GUID) itself, therefore it is impossible to predict the values of the IDs. For this reason, during provisioning a temporary DN is generated by the provisioning logic. This means that on the delta import, following the export of a provisioning add, we have to expect a rename operation for the corresponding add, since the DN of the exported objects change to reflect the value generated by Outlook Live.
In the screenshot above “(OLD)” DN is the temp value produced during provisioning, and the “(NEW)” DN contains the value generated by Outlook Live during export operation.
Even though DN changes, Hosted MA still can maintain the relationship between the objects, since the join is done on different attributes than DN.
In order to maintain the link, even if DN and/or email attributes change, a special non-mutable attribute in Metaverse (OnPremiseObjectDirSyncId) is populated with the ObjectGUID of an AD account. During the export flow the value of the OnPremiseObjectDirSyncId is pushed into DirSyncId attribute in Outlook Live, thus providing the mechanism to maintain the link between objects.