Understanding BPOS Transitions – Directory Synchronization and Source of Authority (SoA)

Posted on Updated on

DirSync

As BPOS tenants go through the Transitions process, they should understand how the BPOS Directory Synchronization Management Agent (MA) is used to synchronize BPOS tenants’ users, contacts, groups and custom domains into Office 365, in preparation for the Transition. As a result the O365 objects are managed via the BPOS DirSync MA and as a result are not able to be managed within Office 365 UNTIL after the BPOS DirSync MA has been disable. This Management of objects is terms Source of Authority and must be fully understood to have meaningful conversations with your BPOS Administrators, so they understand the process and when the BPOS DirSync MA releases its management of objects and allows the Office 365 Administrator to setup their own Directory Synchronization V2 server and services:

Source: http://community.office365.com/en-us/w/sso/directory-synchronization-and-source-of-authority.aspx

In a Microsoft Office 365 environment, source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a cross-premises deployment. For example, by running Active Directory synchronization, you are mastering objects from within your on-premises Active Directory. Alternatively, when you create objects by using the Exchange Control Panel (ECP) or the Office 365 portal, you are mastering objects from within the Office 365 cloud.

Office 365 requires a single source of authority for every object. This reduces the likelihood that directory data could be inadvertently overwritten.

By default, Office 365 directory objects are mastered in the cloud, which means they must be edited by using cloud-based tools. You can use the Office 365 portal, Windows PowerShell, or the ECP to create users, mailboxes, contacts, and groups in the cloud directory. All subsequent changes to these objects are also made by using the same tools. In this scenario, the source of authority is in the cloud.

When the directory synchronization tool is activated in the Office 365 Admin page, and after the first sync cycle has been completed, the source of authority is transferred from the cloud to the on-premises Active Directory. In this scenario, users, contacts, and groups are created on-premises and then synchronized to the cloud. All subsequent changes to the cloud objects (with the exception of licensing) are mastered from the on-premises Active Directory tools. The corresponding cloud objects are read-only. Administrators cannot edit cloud objects if the source of authority is on-premises.

Changing the Source of Authority

There are three scenarios where you may change the source of authority for an object—when you activate, deactivate, or reactivate directory synchronization from within the Office 365 Admin page or with Windows PowerShell. Source of authority is transferred after you perform the first sync.

  • Activate: When you activate directory synchronization and then synchronize directories, the source of authority for any cloud object that is matched to an on-premises object is transferred from the cloud to your on-premises Active Directory.

Activating directory synchronization is a requirement for an Exchange hybrid deployment, an Active Directory Federation Services (ADFS)/single sign-on (SSO), and the staged Exchange migration scenarios.

  • Deactivate: When you deactivate directory synchronization, the source of authority is transferred from the on-premises Active Directory to the cloud.

Deactivating directory synchronization is a requirement if you want to transfer all user, group, contact, and mailbox management to the cloud. For example, some organizations that used the staged Exchange migration tools to move their mailboxes to the cloud and no longer want to manage objects from on-premises can deactivate directory synchronization.

  • Reactivate: When you reactivate directory synchronization, the source of authority is transferred from the cloud back to your on-premises Active Directory (where it previously resided).

It’s important to understand the implications of reactivating directory synchronization in this scenario. Directory data loss can occur when the source of authority is transferred from the cloud back to your on-premises organization.

For example, consider a company that activated directory synchronization in January and created synced users in the cloud. In July, the company deactivates directory synchronization. This transferred the source of authority to the cloud, where the company subsequently edited the objects. In September, the company decided to deploy ADFS/SSO. They reactivated directory synchronization to transfer the source of authority back to the on-premises Active Directory.

In this example, when directory synchronization is reactivated and run, any changes that have been made to the cloud objects from July through September would be overwritten and lost.

The following variables influence whether this example would cause the data for cloud objects to be lost:

  • The matching SMTP and GUID functionality that directory synchronization uses during the reactivate scenario
  • The delta of user property data between the two corresponding objects in their respective directories (your on-premises Active Directory versus the cloud directory)

It’s important to understand these variables so that you can prepare your environment for the source of authority transfer, helping you to minimize directory data loss. Specifically, data loss around email proxy addresses can create mail flow and logon issues for users. Therefore, the focus of your preparation should be on evaluating how you use proxy addresses for mail routing in your current messaging implementation.

  • Matching functionality 1—GUID match logic: When you reactivate directory synchronization, objects in the on-premises Active Directory are matched with objects in the cloud according to previous directory synchronization GUID (objectGUID) on the cloud objects. When such a match is found, the directory synchronization process makes a GUID match and overwrites the target object data in the cloud objects with the data from the corresponding on-premises objects.
  • Matching functionality 2—SMTP match logic: If directory synchronization does not find a GUID match in the cloud, a process called SMTP match is used. In this process, directory synchronization matches corresponding objects, according to the primary SMTP address. If a target (cloud) object’s primary SMTP address matches a primary SMTP address of an object in the on-premises organization, the data for the on-premises object is used to overwrite the data for the corresponding cloud object.

If a GUID or an SMTP match cannot be made, the directory synchronization process creates a new object in the cloud that is mastered from within the on-premises Active Directory.

  • User property delta: The degree and nature of the difference between corresponding user objects in the on-premises and cloud directories are important considerations.

If you have made no changes or have made only minimal changes to the user objects during the time the source of authority was in the cloud, the risk of mail-flow failure is low. If, on the other hand, you have made changes to SMTP addresses (primary, secondary, proxy, target address, and so on) to enable cross-premises routing, you must make sure that reactivating directory synchronization does not interrupt mail flow.

Before you reactivate directory synchronization, we strongly recommend that you back up the existing cloud object data, and then evaluate how you’ve configured SMTP addressing in the cloud.

  • Back up your cloud user object data: Before you reactivate directory synchronization, it is best practice to back up your cloud user object data. You should make a backup even if you have made minimal changes to user objects since you last deactivated directory synchronization.

To make a backup of cloud user object data:

  1. Connect to the cloud by using Windows PowerShell for Exchange. For more information about installing and connecting with remote Windows PowerShell, see Use Windows PowerShell in Exchange Online.
  2. After you connect to the cloud, run the following cmdlet:

Get-Mailbox |select emailaddresses, name, userprincipalname, identity|export-csv -path C:\export\userlist.csv

This cmdlet extracts all user data into Userlist.csv. This file is in the Export directory.

If you want to roll back the reactivation, Userlist.csv helps you to recover user objects to their current state. But it is important to know that rolling back reactivation is a manual, and potentially lengthy, process. You’ll need the help of Microsoft Support.

  • Evaluating SMTP addressing across your messaging organizations: If you have deployed Office 365 in a cross-premises organization and you have configured mail flow between your on-premises Exchange organization and the cloud, it is likely that the user objects are configured with proxy addresses to enable cross-premises mail flow.

To help ensure that mail flow works after you reactivate directory synchronization, copy all relevant proxy addresses from the cloud user objects to their corresponding on-premises objects before you reactivate.

You can use Userlist.csv (that you created for your backup) to validate your SMTP addressing scheme. Additionally, if you are reactivating directory synchronization to enable an Exchange hybrid deployment, you should follow the SMTP addressing recommendations in the Exchange Server Deployment Assistant for your organization. This helps ensure that directory synchronization updates the cloud objects with the correct SMTP addresses.

Deactivate Directory Synchronization by Using Windows PowerShell

If you want to manage objects in Office 365, and you no longer want to use directory synchronization, follow this procedure:

  1. Use Windows PowerShell to manage Office 365.
  2. To deactivate directory synchronization, run the following cmdlet:

Set-MsolDirSyncEnabled –EnableDirSync $false

  • To verify that directory synchronization was deactivated, run the following cmdlet:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

When this command returns False, directory synchronization has been disabled. It may take 72 hours for deactivation to be completed. The time depends on the number of objects that are in your Office 365 subscription account.

Activate or Reactivate Directory Synchronization by using Windows PowerShell

The Windows PowerShell cmdlet to activate or reactive directory synchronization is Set-MsolDirSyncEnabled –EnableDirSync $true.

As previously noted, the reactivate scenario has the potential to overwrite cloud directory object data. Be sure that you understand the variables and consequences of reactivating directory synchronization in your environment.

ADFS/SSO and Directory Synchronization

ADFS/SSO in a cross-premises Office 365 environment requires directory synchronization. When you have enabled and configured ADFS/SSO in your environment, user objects that are mastered on-premises are automatically provisioned with a federated account in the cloud.

If you transfer the source of authority to the cloud by deactivating directory synchronization, new users are not automatically provisioned for ADFS/SSO.

Deactivating directory synchronization does not affect existing federated users in the cloud. They continue to be federated after you deactivate directory synchronization.

Email Migration Scenarios

Transferring the source of authority makes the following email migration scenarios possible:

  • Enabling ADFS/SSO in an existing cloud-only Office 365 messaging environment
  • Decoupling the on-premises Active Directory from a staged Exchange migration environment

Enabling ADFS/SSO in an existing cloud-only Office 365 messaging environment

Enabling ADFS/SSO requires directory synchronization. However, the previous version of the directory synchronization tool could not be run after some of the Exchange migration tools had already been run.

Specifically, a cutover Exchange migration migrates users and mailboxes to the cloud by first creating a user account that is based on the SMTP address.

The previous version of directory synchronization did not create new cloud users if an existing user object in the cloud had the same primary SMTP address as the corresponding on-premises user. However, the current version of directory synchronization uses SMTP match functionality (described earlier in this wiki post) to match on-premises users to cloud users.

Remember that user data associated with matched cloud user objects is overwritten by the corresponding on-premises user data. This is especially important in the case of proxy addresses for complex mail-routing scenarios. Before you transfer the source of authority from the cloud to your on-premises Active Directory, be sure to copy all relevant proxy addresses from the cloud user objects to their corresponding on-premises objects (as described earlier in this wiki post).

See the wiki post, Cutover Exchange Migration and Single Sign-On, for implementation details.

Decoupling the on-premises Active Directory from a staged Exchange migration environment

Running the staged Exchange migration tool requires activating and running directory synchronization. For some organizations, email migration is one phase of a full migration to the cloud. For organizations that want to completely decouple their cloud environment from their on-premises environment, or that want to decommission their on-premises Active Directory, transferring the source of authority to the cloud is likely the final step in their migration plan.

Use SMTP Match to Transfer the Source of Authority for an Office 365 Account to Your On-Premises Active Directory

In some scenarios, you may have to transfer the source of authority for a user account when that account is originally authored by using Office 365 management tools. These tools include the Office 365 portal, Microsoft Online Services Module for Windows PowerShell, and so on. You can transfer the source of authority so that the account can be managed through an on-premises Active Directory Domain Services (AD DS) user account by using directory synchronization.

See the support article:

Whatcha thinkin?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s