How Outlook Live Directory Sync Works

Important:
Outlook Live Directory Sync (OLSync) is the synchronisation solution for Microsoft Live@edu customers. If you are running a cloud-based email service with Microsoft Office 365 for enterprises, you must use the Microsoft Online Services Directory Synchronisation tool to synchronise your directories.

Outlook Live Directory Sync (OLSync) is a directory synchronisation tool that you use to replicate and synchronise user information between your on-premises Active Directory Domain Services (AD DS) or Active Directory directory service and Outlook Live. The goal of directory synchronisation is to represent a single entity in different identity databases, and to keep the information about that entity consistent and up-to-date. In addition, OLSync auto-provisions accounts in Outlook Live based on how you have configured OLSync and your on-premises recipient objects.

OLSync is designed to simplify the complex task of directory synchronisation. Before you deploy OLSync, you need a high-level understanding about how directory synchronisation works and some basic concepts behind the supported identity management tools, Microsoft Forefront Identity Manager (FIM) 2010 and Microsoft Identity Lifecycle Manager (ILM) 2007. There are two versions of OLSync: the 64-bit version relies on FIM 2010 as its directory synchronisation engine, and the 32-bit version relies on ILM 2007.

In addition, you need to understand how OLSync determines which on-premises recipient objects to include in synchronisation and provisioning. And finally, you must understand how the specific configuration of the recipient objects and OLSync determines the final synchronisation and provisioning behaviour of the resulting recipient objects in Outlook Live.

How will this understanding help you?

• Planning   An understanding of how OLSync works will help you plan for initial deployment and account provisioning. A basic OLSync infrastructure is fairly easy to deploy, but if your organisation grows or you want to deploy additional Outlook Live domains in the future, you'll need to understand how best to plan for directory synchronisation in a more complex deployment.
  
• Security   You need to understand which recipient objects are being replicated to the Outlook Live domain and the implications for privacy and security. For example, recipient data, such as name, phone, title, office and other personal information, is synchronized to and exposed in the Outlook Live shared address book. Also, you will need to create service accounts in your cross-premises organisation that have elevated rights.
  
• Troubleshooting   After you set up OLSync, running and maintaining the solution isn't hard. However, deployment relies on a number of manual configurations that can be error-prone. Understanding how OLSync works will help you troubleshoot potential connection and configuration errors.
  

In this topic, we cover the following:

• Basic identity management terminology
  
• OLSync filtering logic
  
• How is each object synchronised?
  

Because FIM 2010 or ILM 2007 is used as the directory synchronisation engine by OLSync, it's helpful to understand the following terms as they relate to these tools.

Top of page

Filtering occurs during the import operation in a synchronisation cycle. The goal of filtering is to determine which recipient objects in the on-premises AD DS or Active Directory should be copied to the metaverse for synchronisation.

When OLSync runs, FIM 2010 or ILM 2007 filters out objects in the following order. After an object is filtered out, FIM 2010 or ILM 2007 won't evaluate it again, nor will the object be copied to the metaverse for synchronisation.

1. Recipient objects that don't have required attributes   FIM 2010 or ILM 2007 reads the following recipient objects. If any of the required attributes are empty (null), the recipient object is filtered out.
   

   Recipient object type	Required attributes
   Mailbox-enabled user	mail, legacyExchangeDN, proxyAddresses
   Mail-enabled user	mail, targetAddress
   User (AD DS or Active Directory only; no Microsoft Exchange installed)	mail
   Mail-enabled contact	mail, targetAddress
   Distribution group, dynamic distribution group or security group	mail, proxyAddresses, mailNickName

2. Recipient objects where the adminCount attribute is set to 1   The adminCount attribute is used to identify users in protected administrator groups, such as the Domain Admins and Administrators. If the adminCount attribute is set to 1 on any recipient object, it is filtered out.
   
3. Mailbox-enabled user objects that are specified as mailbox plans, discovery mailboxes or arbitration mailboxes   The msExchRecipientTypeDetails attribute is used to identify mailboxes that are specified as mailbox plans, discovery mailboxes or arbitration mailboxes. These mailbox-enabled users are filtered out.
   
4. The mail attribute on an AD DS or Active Directory-only user that doesn't match the provisioning domain   In an on-premises environment where Microsoft Exchange hasn't been installed, OLSync filters out all user objects where the mail attribute doesn't contain an SMTP address that matches the provisioning domain.
   
5. The attribute used to generate the Windows Live ID doesn't match any of the accepted domains   The final pass filters out recipient objects that are configured for auto-provisioning but don't have an accepted domain match in the attribute that is used to generate the Windows Live ID.
   The attribute used to generate the Windows Live ID must contain a domain name that matches one of the accepted domains that you have configured in Outlook Live. As described in step 4, by default, OLSync looks to the user principal name (UPN) for a match unless you have set the MVWindowsLiveIdAttributeName parameter to use a different attribute. In this case, OLSync matches the SMTP address that is stored in the attribute that you have specified in the MVWindowsLiveIdAttributeName parameter. In any case, if OLSync can't find a match to an accepted domain, the recipient object is filtered out.
   

Top of page

Now let's look at how different recipient object types are synchronised from your on-premises domain to Outlook Live.

Before we describe how each recipient object type is handled, let's take a look at some important concepts.

In the context of OLSync synchronisation and provisioning, accepted domains are important. As a best practice, all the domains in your on-premises forest should be represented and configured as accepted domains in your Outlook Live deployment. In addition, all users in your on-premises forest should have UPNs that match one of the accepted domains in your Outlook Live deployment. An important change to the most recent version of OLSync is how new accepted domains are handled after OLSync has already run. Depending on your configuration, OLSync may delete or create new recipient objects in Outlook Live if you add or remove an accepted domain.

For example, consider an organization with on-premises mail-enabled users whose targetAddress attributes don't match an accepted domain in Outlook Live. When OLSync is run, external contacts are provisioned in Outlook Live that correspond to the on-premises mail-enabled users. Now, the administrator adds an accepted domain to Outlook Live that matches the targetAddress attributes on the mail-enabled users. The next time OLSync is run, the external contacts that were created previously are deleted and a mail-box enabled users are created instead.

Provisioning domain, targetAddress, and UPN

As you think about deploying OLSync and how you will provision users, it's important to understand the relationship between the provisioning domain, the targetAddress attribute, and the userPrincipalName attribute. You will need to prepare the recipient objects in your on-premises domain before you deploy OLSync. How the targetAddress and userPrincipalName attributes are set on these recipient objects will dictate how OLSync will auto-provision users.

The provisioning domain is used by OLSync as a trigger for provisioning. You must specify at least one provisioning domain when you configure OLSync. If the OLSync provisioning domain parameter includes a domain that matches a targetAddress value on a given mail-enabled user in the on-premises AD DS or Active Directory, provisioning is triggered.

By default, if the on-premises UPN domain name for the given recipient object doesn't match an accepted domain, OLSync won't provision a user. On the other hand, if the on-premises UPN does match an accepted domain in Outlook Live, provisioning will work.

By default, when OLSync provisions a Windows Live ID for a user, the Windows Live ID for the provisioned user matches the on-premises UPN domain. However, the resulting Windows Live ID for the provisioned user is can be changed by setting the MVWindowsLiveIdAttributeName parameter.

The following diagram shows how each recipient object can be synchronised.

Top of page

Implement Outlook Live Directory Sync for Live@edu

• How Outlook Live Directory Sync Works
  
• Plan Your Outlook Live Directory Sync Deployment for Live@edu
  
• Deploy Outlook Live Directory Sync for Live@edu
  
  • OLSync Prerequisites
    
  • Prepare Your On-Premises Organisation for OLSync
    
  • Create an OLSync Service Account in Outlook Live
    
  • Create an On-Premises OLSync Service Account
    
  • Run OLSync Setup
    
  • Configure the OLSync Hosted Management Agent
    
  • Specify the On-Premises Organisational Units that are Synchronised to Outlook Live
    
  • Configure Password Change Notification Service (PCNS) for use with OLSync for Live@edu (optional)
    
  • Perform a Full OLSync Synchronisation to Outlook Live
    
  • Verify OLSync Synchronisation to Outlook Live
    
  • Perform Subsequent OLSync Data Synchronisations to Outlook Live
    
• Outlook Live Directory Sync Reference