Topic Last Modified: 2009-10-29
Outlook Live Directory Sync (OLSync) is a directory synchronization tool that you use to replicate and synchronize user information between your on-premises Active Directory Domain Services (AD DS) or Active Directory directory service and Outlook Live. The goal of directory synchronization 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 synchronization. Before you deploy OLSync, you need a high-level understanding about how directory synchronization works and some basic concepts behind Microsoft Identity Lifecycle Manager (ILM) 2007. OLSync relies on ILM 2007 Feature Pack 1 (FP1) as its directory synchronization engine.
In addition, you need to understand how OLSync determines which on-premises recipient objects to include in synchronization and provisioning. And finally, you must understand how the specific configuration of the recipient objects and OLSync determines the final synchronization and provisioning behavior 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 organization grows or you want to deploy additional Outlook Live domains in the future, you'll need to understand how best to plan for directory synchronization 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 organization 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 ILM 2007 terminology
Because ILM 2007 is the directory synchronization engine used by OLSync, it's helpful to understand the following terms as they relate to ILM 2007.
| Term | Definition |
|---|---|
Active Directory Management Agent (ADMA) | The ILM management agent provided by Microsoft to connect to AD DS or Active Directory. |
Connector space | A staging area in ILM that contains representations of selected objects and attributes in a connected data source, such as AD DS or Active Directory. The connector space contains a mirror image of the connected data source at a given point in time. |
Connector space entry | An object in the ILM connector space that is either created by data imported from the connected data source or by provisioning. These objects hold attribute values that can be imported or exported from corresponding objects in the connected data source or the metaverse. |
Outlook Live Management Agent (OLMA) | The ILM management agent provided by Microsoft to connect to Outlook Live. |
Management agent | An ILM component that consists of properties, rules, and rules extensions that determine how an object is processed. A single management agent can have one or more run profiles that determine the management agent's behavior, such as how or when the management agent runs. Each management agent has a connector space associated with it. |
Metaverse | The data store used by ILM to contain the aggregated identity information from multiple connected data sources, providing a single global, integrated view of all combined objects. The metaverse is the core identity repository for ILM and is often referred to as the metadirectory. |
Synchronization | The ILM operation that copies information back and forth between a connector space and the metaverse, and applies appropriate rules to the data. There are two types of import and synchronization operations: full and "delta". A full import or synchronization occurs initially when a new connector space has been configured. Subsequent operations synchronize only data that is new or changed, that is, the "delta", or difference, since the last synchronization. Delta operations are much faster. However, full operations may be needed again at some point because of certain kinds of error conditions. ILM 2007 prompts you to run full operations if they are required. If you update the binary files that are included with OLSync or if you change the default rules, for example by configuring custom attribute flows, you must also run a full synchronization cycle. |
OLSync filtering logic
Filtering occurs during the import operation in an ILM synchronization 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 ILM metaverse for synchronization.
When OLSync runs, ILM filters out objects in the following order. After an object is filtered out, ILM won't evaluate it again, nor will the object be copied to the ILM metaverse for synchronization.
- Recipient objects that don't have required attributes ILM 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
- 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.
- 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.
- 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.
- 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.
How is each object synchronized?
Now let's look at how different recipient object types are synchronized 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.
| Term | Definition |
|---|---|
Security principal objects | Active Directory objects that are assigned security IDs (SIDs) and can be used to log on to the network and can be assigned access to domain resources. |
Provisioning domain | The domain name of the Outlook Live domain that you are configuring with OLSync. When you deploy OLSync, you manually enter at least one provisioning domain, for example, student.contoso.edu, during the ILM 2007 configuration process. The provisioning domain must be an accepted domain in your Outlook Live deployment. To simplify the mail-routing configuration between your on-premises organization and Outlook Live, we recommend that the provisioning domain is also an authoritative domain in your Outlook Live organization. With this configuration, the on-premises mail-enabled users' targetAddress attribute will point to the authoritative domain in Outlook Live. Therefore, e-mail sent to the on-premises mail-enabled user will be routed to the corresponding Outlook Live mailbox without additional on-premise routing configuration. |
Accepted domain | Any SMTP namespace for which an Outlook Live organization sends or receives e-mail. OLSync uses the Outlook Live accepted domain data to determine what kind of Exchange recipient objects to create in the Outlook Live domain. For more information, see Accepted Domains. |
On-premises schema | In addition to the Outlook Live accepted domain, the Active Directory schema that is running on-premises also dictates what kind of Exchange recipient objects OLSync creates in the Outlook Live domain. OLSync acts on an Active Directory schema where Microsoft Exchange hasn't been installed. OLSync also acts on the Active Directory schema where Microsoft Exchange Server 2003 or later versions of Microsoft Exchange has been installed. |
targetAddress attribute | The targetAddress attribute is an Active Directory attribute on Exchange recipient objects. In an Exchange environment, the targetAddress attribute is exposed as the "External address" address, and is used for routing e-mail. |
In the context of OLSync synchronization 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.
Mail-enabled user objects
A mail-enabled user object is an Active Directory security principal object that has at least one associated SMTP address. By default, a mail-enabled user object has a mail, targetAddress, and proxyAddresses attribute. By default, each of these attributes shares the same e-mail value.
When OLSync encounters a mail-enabled user object in your on-premises forest, it creates one of the following three types of objects in the corresponding Outlook Live organization, depending on the mail-enabled user's targetAddress attribute.
- The mail-enabled user is synchronized to Outlook Live as a mailbox-enabled user object If the mail-enabled user's targetAddress attribute matches a provisioning domain, an Outlook Live mailbox is provisioned for the user. The resulting Windows Live ID for the provisioned user is controlled by the MVWindowsLiveIdAttributeName parameter. By default, the Windows Live ID will match the on-premises user's UPN.
- The mail-enabled user is synchronized to Outlook Live as a mail-enabled user If the mail-enabled user's targetAddress attribute doesn't match a provisioning domain, but it does match an accepted domain in the Outlook Live organization, a mail-enabled user is created in Outlook Live. However, a Windows Live ID isn't created for this account.
- The mail-enabled user is synchronized to Outlook Live as an external contact If the mail-enabled user's targetAddress attribute doesn't match a provisioning domain, and it also doesn't match an accepted domain in the Outlook Live organization, an external contact is created in Outlook Live. Outlook Live represents external users as external contacts, while internal users are represented by mail-enabled users. OLSync distinguishes internal and external users according to whether the associated targetAddress attribute matches an accepted domain or not.
Mailbox-enabled user objects
A mailbox-enabled user object is an Active Directory security principal object that has Exchange-specific attributes, such as homeMDB.
When you run OLSync, mailbox-enabled user objects in your on-premises organization are synchronized to the Microsoft datacenter as either mail-enabled user objects or mail contacts. This means the Outlook Live address book contains all the users from your on-premises organization.
Mailbox-enabled user objects don't have a targetAddress attribute in Active Directory. Therefore, when OLSync runs, it reads the proxyAddresses attribute to determine how to synchronize the object to Outlook Live.
If the proxyAddresses attribute contains a primary SMTP address that matches an accepted domain in Outlook Live, a mail-enabled user is created. For the purposes of e-mail routing, the targetAddress attribute on the corresponding mail-enabled user in Outlook Live will match the primary SMTP address of the on-premises mailbox-enabled user.
If, on the other hand, the proxyAddresses attribute doesn't contain a primary SMTP address that matches an accepted domain in Outlook Live, then a mail contact is created.
Mail contacts
A mail contact isn't a security principal object. It is an object that has at least one SMTP address associated with it. Use mail contacts to represent people outside of your organization who have external e-mail addresses and to whom users in your organization frequently send mail.
When OLSync encounters a mail contact object in your on-premises forest, it creates one of the following two types of objects in the corresponding Outlook Live organization, depending on the external contact's targetAddress attribute.
- The mail contact is synchronized to Outlook Live as an external contact If the mail contact's targetAddress attribute doesn't match an Outlook Live accepted domain, an external contact is created in Outlook Live.
- The mail contact is synchronized to Outlook Live as a mail-enabled user If the mail contact's targetAddress attribute matches an accepted domain in the Outlook Live organization, a mail-enabled user is created in Outlook Live.
Groups
A group can be a security group or an e-mail distribution group, which is called a "public group" in Outlook Live. Security groups are security principal objects. You can mail-enable a security group but this isn't a best practice.
E-mail distribution groups, security groups, and dynamic distribution groups don't have a targetAddress attribute on their respective objects in Active Directory. Therefore, when OLSync runs, it reads the proxyAddresses attribute to discover the primary SMTP address, which in turn, determines how OLSync synchronizes the object to Outlook Live.
If the primary SMTP address of a given e-mail distribution group, security group or dynamic distribution group is set to any accepted domain, they are synchronized to Outlook Live as mail-enabled users. Groups that have a primary SMTP address that doesn't match an accepted domain are synchronized to Outlook Live as external mail contacts. In both cases, groups that are synchronized to Outlook Live don't expose the objects in the on-premises group to Outlook Live users.
Quick guide to how objects are synchronized
The following tables summarize how objects are synchronized. The first table shows recipient objects that are present in an organization that is running Microsoft Exchange. The second table shows a user object in an Active Directory organization where Microsoft Exchange isn't installed.
| On-premises recipient object - Microsoft Exchange on-premises | Configuration of the on-premises recipient object | Synchronized to Outlook Live as: |
|---|---|---|
Mail-enabled user | The targetAddress attribute of the on-premises recipient object is set to the provisioning domain. | Mailbox-enabled user |
Mail-enabled user | The targetAddress attribute of the on-premises recipient object is set to the accepted domain that isn't a provisioning domain. | Mail-enabled user |
Mail-enabled user | The targetAddress attribute of the on-premises recipient object is set to the neither the provisioning domain nor the accepted domain. | External contact |
Mail contact | The targetAddress attribute of the on-premises recipient object is set to the neither the provisioning domain nor the accepted domain. | External contact |
Mail contact | The targetAddress attribute of the on-premises recipient object is set to any accepted domain. | Mail-enabled user |
Mailbox-enabled user | The primary SMTP address of on-premises recipient object is set to any accepted domain. | Mail-enabled user |
Mailbox-enabled user | The primary SMTP address of on-premises recipient object is not set to any accepted domain. | External contact |
Distribution group, dynamic distribution group, or security group | The primary SMTP address of on-premises recipient object is set to any accepted domain. | Mail-enabled user |
Distribution group, dynamic distribution group, or security group | The primary SMTP address of on-premises recipient object is set to neither the provisioning domain nor the accepted domain. | External contact |
| On-premises recipient object - Active Directory only, no Microsoft Exchange on-premises | mail attribute of on-premises user object set to: | Synchronized to Outlook Live as: |
|---|---|---|
Active Directory user | Provisioning domain | Mailbox-enabled user |
Active Directory contact |
| Not synchronized |
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 synchronized.
Read more
Implement Outlook Live Directory Sync
- How Outlook Live Directory Sync Works
- Plan Your Outlook Live Directory Sync Deployment
- Deploy Outlook Live Directory Sync
- OLSync Prerequisites
- Prepare Your On-Premises Organization 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 Organizational Units that are Synchronized to Outlook Live
- Perform a Full OLSync Synchronization to Outlook Live
- Verify OLSync Synchronization to Outlook Live
- Perform Subsequent OLSync Data Synchronizations to Outlook Live
- OLSync Prerequisites
- Outlook Live Directory Sync Reference
