Plan Your Outlook Live Directory Sync Deployment for Live@edu

OLSync uses the Outlook Live accepted domain information when it synchronises and auto-provisions mailboxes.

As you learned in How Outlook Live Directory Sync Works, OLSync introduces the concept of a provisioning domain. The provisioning domain is one or more accepted domains in your Outlook Live deployment. OLSync determines whether auto-provisioning should be triggered based on whether the targetAddress attribute value is a provisioning domain. Provisioning domains are specified during the OLSync configuration process. If the OLSync provisioning domain parameter includes a domain that matches a targetAddress value on a given mail-enabled user or a mail contact in the on-premises AD DS or Active Directory, provisioning is triggered.

If the on-premises user principal name (UPN) domain name for the given recipient object matches an accepted domain in Outlook Live, provisioning will occur.

So let's look at our example: Contoso University has on-premises Exchange mailboxes with SMTP addresses of user@contoso.edu. The goal is to provide all staff, administration and faculty with on-premises mailboxes. Students will have mailboxes in Outlook Live in the student.contoso.edu domain.

What do the Contoso University administrators need to do? Before deploying OLSync, they should configure Outlook Live with student.contoso.edu as an accepted domain in Outlook Live.

The administrators must configure an alternate user principal name (UPN) suffix in the on-premises Active Directory forest. The alternate UPN suffix must match the accepted domain that they configured in Outlook Live. When OLSync provisions a Windows Live ID for a user, the Windows Live ID for the provisioned user matches the on-premises user principal name (UPN) domain. Therefore, the on-premises UPN must match an accepted domain in Outlook Live. For information about how to add UPN suffixes in your organisation, see Add user principal name suffixes.

Note   You can override this default behaviour to use a different SMTP address to determine the Windows Live ID. For more information, see Parameters for the OLSync Hosted Management Agent.

As explained in How Outlook Live Directory Sync Works, the type of Exchange recipient objects that are auto-provisioned into Outlook Live is dictated by the on-premises recipient object type (user, mail-enabled user, mailbox-enabled users, etc.) and the corresponding targetAddress attribute value on the object. Before you synchronise using OLSync, you must make sure all your on-premises Exchange recipient objects are configured so that they'll auto-provision into Outlook Live as you expect them to.

For the purposes of auto-provisioning in the Contoso University example, OLSync must be configured with a provisioning domain set to student.contoso.edu, and the recipient objects must be configured as follows:

• Mail-enabled user objects   All students who need Outlook Live mailboxes must be represented in the on-premises Contoso University directory as mail-enabled user objects with the targetAddress attribute set to student.contoso.edu. The UPN attribute also must be set to student.contoso.edu. If Contoso University were deploying a shared namespace, the UPN would be set to contoso.edu, and contoso.edu would also have to be an accepted domain in Outlook Live.
  Mail-enabled user objects that don't have an accepted domain specified in the targetAddress attribute are synchronised as external contacts with the same email address that is specified on the on-premises object's targetAddress attribute.
  
• Mailbox-enabled user objects, distribution groups and dynamic distribution groups   As a best practice, these recipient objects should be synchronised to Outlook Live as mail-enabled users. On-premises mailbox-enabled users, distribution groups and dynamic distribution groups that have the primary SMTP address configured to match any accepted domain in Outlook Live synchronise to Outlook Live as mail-enabled users. In the Contoso University example, these recipient objects would likely share the primary SMTP address, contoso.edu. Therefore, the Contoso University administrators must add contoso.edu as an accepted domain in Outlook Live.
  Mailbox-enabled user objects, distribution groups or dynamic distribution groups whose objects don't have a primary SMTP address that matches an accepted domain in Outlook Live are synchronised as external mail contacts.
  
• Mail contacts   Contoso University has two types of mail contacts in their on-premises Active Directory. OLSync provisions different recipient types in Outlook Live depending on how the targetAddress attribute of the on-premises contact is configured and whether the targetAddress attribute matches an accepted domain in Outlook Live. The two types of contacts are:
  
  • Those that represent faculty and staff in other departments of the university where the other departments don't use Microsoft Exchange or Active Directory   In this case, the domain name used for the contacts likely matches the domain name used for mailbox-enabled users in Microsoft Exchange. In this example, the contacts would have contoso.edu e-mail addresses. These are known as "internal" contacts. For the purposes of potential migration in the future, we recommend provisioning these contacts as mail-enabled users in Outlook Live. To achieve this, the administrators at Contoso University must make sure that all domain names that are used by internal contacts are configured in Outlook Live as accepted domains.
    
  • Those that represent external contacts outside the university   These types of contacts, whose targetAddress attribute doesn't match an accepted domain in Outlook Live, are synchronised to Outlook Live as external contacts. The targetAddress attribute of the on-premises mail contact is used as the SMTP address on the new external mail contact in Outlook Live.
    

Note   In organisations where AD DS or Active Directory is deployed, but Microsoft Exchange Server 2000 or later hasn't been installed, OLSync operates in what is called "AD-Only" mode. In AD-Only mode, OLSync reads the WindowsEmailAddress Active Directory attribute instead of the targetAddress attribute.

To learn how to set the targetAddress attribute and primary SMTP address on recipient objects, see Prepare Your On-Premises Organisation for OLSync.

Here’s how custom and extension attributes are handled by OLSync:

1. By default, on-premises extension attributes (extensionAttribute1 - extensionAttribute15) are synchronised to the corresponding custom attributes (customAttribute1 - customAttribute15) in Outlook Live.
   
2. Multi-value extension attributes (ExtensionCustomAttribute1 - ExtensionCustomAttribute5) can’t be synchronised between on-premises and Outlook Live. Instead, you need to write a custom PowerShell script to synchronise these attributes in both directions, from on-premises and from Outlook Live. Note that these attributes are only available on-premises in Exchange Server 2010 SP2 and later versions.
   

A shared address space with OLSync is basically the same as the shared address space scenario that is described in Shared Address Space with On-Premises Relay. Users in Outlook Live and in your on-premises organisation have a contoso.edu email address and user logon name. All incoming messages are first delivered to the on-premises organisation before being routed to Outlook Live. For more information, see Shared Address Space with Outlook Live Directory Sync.

When OLSync accesses your on-premises directory, it reads the data and filters out everything that isn't an Exchange recipient object. OLSync then copies those objects into the FIM 2010 or ILM 2007 ADMA connector space. In addition to read access to each domain where recipient objects are stored, OLSync needs to be able to read replication data in each domain where Exchange recipients are stored. Because OLSync doesn't write back to your on-premises directory, this is a low access service account. The service account is a normal domain user account that has "Replicating directory changes" permissions for each domain where Exchange recipients are stored. To learn how to create the on-premises service account, see Create an On-Premises OLSync Service Account.

To authenticate with Outlook Live, you must create and use a Windows Live ID service account. OLSync requires write access to the Outlook Live directory partition for your domain or domains. Therefore, the access provided to the service account is much higher than the access that is required for the on-premises OLSync service account.

Fortunately, there is a role based access control (RBAC) role, GALSynchronizationManagement, which is specific to the OLSync service account, so it's easy to apply permissions to the service account. After you create a Windows Live ID with a mailbox in your Outlook domain, you assign the GALSynchronizationManagement role to the user, and then enable the account for Windows PowerShell.

To view the exact permissions that the GALSynchronizationManagement role applies to the service account, run the following command in your Outlook Live domain with your Outlook Live administrator account.

Get-ManagementRoleEntry GALSynchronizationManagement\* | ConvertTo-HTML  <path_fileName>.htm

The command creates a Web page that lists the permissions. To learn how to create the Windows Live ID service account, see Create an OLSync Service Account in Outlook Live.

In this release of OLSync, the initial password is created by a FIM 2010 or ILM 2007 rule extension as part of OLSync. The initial passwords are set on the provisioned Windows Live accounts in Outlook Live. The Windows Live account alias and corresponding passwords are stored on the FIM 2010 or ILM 2007 server in a plain text XML file. As the administrator, you must distribute these initial passwords to the users.

Note:
You can also develop a custom rule extension in FIM 2010 or ILM 2007 to create initial passwords in a way that might better suit your organisation. Alternatively, you can develop a solution that synchronises an already-generated password from an existing source system to the target using an attribute value. Such customisations require FIM 2010 or ILM 2007 expertise.

By default, users aren't required to change their passwords after they sign in for the first time. You can force users to reset their password when they sign in for the first time by setting the ResetPasswordOnFirstLogon parameter in FIM 2010 or ILM 2007. Learn how in Configure the OLSync Hosted Management Agent.

In the default behaviour, users manage their own password after they sign in. However, you can use Windows PowerShell to force users to reset their passwords.

FIM 2010 and ILM 2007 FP1 support the Password Change Notification Service (PCNS). PCNS is a service that runs on a domain controller with AD DS or Active Directory and allows password changes that originate from the directory to be propagated to Outlook Live.

In the context of the initial password, if you are running PCNS, you don't need to distribute the auto-generated passwords to your users. Instead, tell you users to change their password on their on-premises Active Directory account. PCNS will then change the password for the corresponding Outlook Live account. Users can then sign in to their Outlook Live account using the same password that they use for their on-premises Active Directory account.

For information on how to set up and configure PCNS, see Configure Password Change Notification Service (PCNS) for use with OLSync for Live@edu.

When you set up PCNS, we recommend using a dedicated service account for PCNS only. Don't use the same service account that you specified for the OLSync configuration.

Windows Live@edu provides an SDK that explains how to create a single sign-on portal for your Outlook Live users. The portal delegates access to Outlook Live using a Windows Live-issued authentication certificate. After users authenticate with your portal, they can then sign in to Outlook Live. In the context of OLSync, the single sign-on portal solution is ideal for customers who aren't running AD DS or Active Directory as their primary user authentication mechanism. Otherwise, using Connected Federation or PCNS is recommended. For more information, sign in to the Live@edu Service Management Portal and click Single sign-on.