Skip to content

Azure AD Connect: Update PreferredDataLocation #4472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
1 commit merged into from
Jan 25, 2018
Merged

Azure AD Connect: Update PreferredDataLocation #4472

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion articles/active-directory/connect/active-directory-aadconnect-topologies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,10 +107,11 @@ In this scenario, one (or more) resource forest trusts all account forests. The
Some Office 365 workloads have certain restrictions on supported topologies:

| Workload | Restrictions |
--------- | ---------
| --------- | --------- |
| Exchange Online | For more information about hybrid topologies supported by Exchange Online, see [Hybrid deployments with multiple Active Directory forests](https://technet.microsoft.com/library/jj873754.aspx). |
| Skype for Business | When you're using multiple on-premises forests, only the account-resource forest topology is supported. For more information, see [Environmental requirements for Skype for Business Server 2015](https://technet.microsoft.com/library/dn933910.aspx). |

If you are a larger organization, then you should consider to use the [Office 365 PreferredDataLocation](active-directory-aadconnectsync-feature-preferreddatalocation.md) feature. It allows you to define in which datacenter region the user's resocues are located.

## Staging server
![Staging server in a topology](./media/active-directory-aadconnect-topologies/MultiForestStaging.png)
Expand Down
223 changes: 1 addition & 222 deletions ...e-directory/connect/active-directory-aadconnectsync-change-the-configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ ms.workload: identity
ms.tgt_pltfrm: na
ms.devlang: na
ms.topic: article
ms.date: 01/03/2018
ms.date: 01/13/2018
ms.author: billmath

---
Expand Down Expand Up @@ -168,227 +168,6 @@ You can instruct the Sync Engine that you want additional rules inserted before

You can have many custom sync rules using the same **PrecedenceBefore** value when needed.

## Enable synchronization of PreferredDataLocation
By default, Office 365 resources for your users are located in the same region as your Azure AD tenant. For example, if your tenant is located in North America then the users Exchange mailboxes are also located in North America. For a multi-national organization this might not be optimal. By setting the attribute preferredDataLocation the user's region can be defined.

The regions in Office 365 are:

| Region | Description |
| --- | --- |
| NAM | North America |
| EUR | Europe |
| APC | Asia Pacific |
| JPN | Japan |
| AUS | Australia |
| CAN | Canada |
| GBR | Great Britain |
| LAM | Latin America |

Not all Office 365 workloads supports the use of setting a user's region.

Azure AD Connect supports synchronization of the **PreferredDataLocation** attribute for **User** objects in version 1.1.524.0 and after. More specifically, following changes have been introduced:

* The schema of the object type **User** in the Azure AD Connector is extended to include PreferredDataLocation attribute, which is of type single-valued string.

* The schema of the object type **Person** in the Metaverse is extended to include PreferredDataLocation attribute, which is of type string and is single-valued.

By default, the PreferredDataLocation attribute is not enabled for synchronization because there is no corresponding PreferredDataLocation attribute in on-premises Active Directory. You must manually enable synchronization.

> [!IMPORTANT]
> Currently, Azure AD allows the PreferredDataLocation attribute on both synchronized User objects and cloud User objects to be directly configured using Azure AD PowerShell. Once you have enabled synchronization of the PreferredDataLocation attribute, you must stop using Azure AD PowerShell to configure the attribute on **synchronized User objects** as Azure AD Connect will override them based on the source attribute values in on-premises Active Directory.

> [!IMPORTANT]
> Since September 1, 2017, Azure AD no longer allows the PreferredDataLocation attribute on **synchronized User objects** to be directly configured using Azure AD PowerShell. To configure PreferredLocation attribute on synchronized User objects, you must use Azure AD Connect.

Before enabling synchronization of the PreferredDataLocation attribute, you must:

* First, decide which on-premises Active Directory attribute to be used as the source attribute. It should be of type **single-valued string**. In the steps below one of the extensionAttributes is used.

* If you have previously configured the PreferredDataLocation attribute on existing synchronized User objects in Azure AD using Azure AD PowerShell, you must **backport** the attribute values to the corresponding User objects in on-premises Active Directory.

> [!IMPORTANT]
> If you do not backport the attribute values to the corresponding User objects in on-premises Active Directory, Azure AD Connect will remove the existing attribute values in Azure AD when synchronization for the PreferredDataLocation attribute is enabled.

* It is recommended you configure the source attribute on at least a couple of on-premises AD User objects now, which can be used for verification later.

The steps to enable synchronization of the PreferredDataLocation attribute can be summarized as:

1. Disable sync scheduler and verify there is no synchronization in progress
2. Add the source attribute to the on-premises AD Connector schema
3. Add PreferredDataLocation to the Azure AD Connector schema
4. Create an inbound synchronization rule to flow the attribute value from on-premises Active Directory
5. Create an outbound synchronization rule to flow the attribute value to Azure AD
6. Run Full Synchronization cycle
7. Enable sync scheduler

> [!NOTE]
> The rest of this section covers these steps in details. They are described in the context of an Azure AD deployment with single-forest topology and without custom synchronization rules. If you have multi-forest topology, custom synchronization rules configured or have a staging server, you need to adjust the steps accordingly.

### Step 1: Disable sync scheduler and verify there is no synchronization in progress
Ensure no synchronization takes place while you are in the middle of updating synchronization rules to avoid unintended changes being exported to Azure AD. To disable the built-in sync scheduler:

1. Start a PowerShell session on the Azure AD Connect server.
2. Disable scheduled synchronization by running the cmdlet: `Set-ADSyncScheduler -SyncCycleEnabled $false`.
3. Start the **Synchronization Service Manager** by going to **START** > **Synchronization Service**.
4. Go to the **Operations** tab and confirm there is no operation with the status *in progress*.

![Synchronization Service Manager - check no operations in progress](./media/active-directory-aadconnectsync-change-the-configuration/preferredDataLocation-step1.png)

### Step 2: Add the source attribute to the on-premises AD Connector schema
Not all AD attributes are imported into the on-premises AD Connector Space. If you have selected to use an attribute not synchronized by default, then you need to import it. To add the source attribute to the list of the imported attributes:

1. Go to the **Connectors** tab in the Synchronization Service Manager.
2. Right-click the **on-premises AD Connector** and select **Properties**.
3. In the pop-up dialog, go to the **Select Attributes** tab.
4. Make sure the source attribute you selected to use is checked in the attribute list.
5. Click **OK** to save.

![Add source attribute to on-premises AD Connector schema](./media/active-directory-aadconnectsync-change-the-configuration/preferredDataLocation-step2.png)

### Step 3: Add PreferredDataLocation to the Azure AD Connector schema
By default, the PreferredDataLocation attribute is not imported into the Azure AD connector space. To add the PreferredDataLocation attribute to the list of imported attributes:

1. Go to the **Connectors** tab in the Synchronization Service Manager.
2. Right-click the **Azure AD Connector** and select **Properties**.
3. In the pop-up dialog, go to the **Select Attributes** tab.
4. Select the PreferredDataLocation attribute in the attribute list.
5. Click **OK** to save.

![Add source attribute to Azure AD Connector schema](./media/active-directory-aadconnectsync-change-the-configuration/preferredDataLocation-step3.png)

### Step 4: Create an inbound synchronization rule to flow the attribute value from on-premises Active Directory
The inbound synchronization rule permits the attribute value to flow from the source attribute from on-premises Active Directory to the Metaverse:

1. Start the **Synchronization Rules Editor** by going to **START** > **Synchronization Rules Editor**.
2. Set the search filter **Direction** to be **Inbound**.
3. Click **Add new rule** button to create a new inbound rule.
4. Under the **Description** tab, provide the following configuration:

| Attribute | Value | Details |
| --- | --- | --- |
| Name | *Provide a name* | For example, *“In from AD – User PreferredDataLocation”* |
| Description | *Provide a custom description* | |
| Connected System | *Pick the on-premises AD connector* | |
| Connected System Object Type | **User** | |
| Metaverse Object Type | **Person** | |
| Link Type | **Join** | |
| Precedence | *Choose a number between 1 – 99* | 1 – 99 is reserved for custom sync rules. Do not pick a value that is used by another synchronization rule. |

5. Keep the **Scoping filter** empty to include all objects. You may need to tweak the scoping filter according to your Azure AD Connect deployment.
6. Go to the **Transformation tab** and implement the following transformation rule:

| Flow Type | Target Attribute | Source | Apply Once | Merge Type |
| --- | --- | --- | --- | --- |
|Direct | PreferredDataLocation | Pick the source attribute | Unchecked | Update |

7. Click **Add** to create the inbound rule.

![Create inbound synchronization rule](./media/active-directory-aadconnectsync-change-the-configuration/preferredDataLocation-step4.png)

### Step 5: Create an outbound synchronization rule to flow the attribute value to Azure AD
The outbound synchronization rule permits the attribute value to flow from the Metaverse to the PreferredDataLocation attribute in Azure AD:

1. Go to the **Synchronization Rules** Editor.
2. Set the search filter **Direction** to be **Outbound**.
3. Click **Add new rule** button.
4. Under the **Description** tab, provide the following configuration:

| Attribute | Value | Details |
| ----- | ------ | --- |
| Name | *Provide a name* | For example, “Out to AAD – User PreferredDataLocation” |
| Description | *Provide a description* ||
| Connected System | *Select the AAD connector* ||
| Connected System Object Type | User ||
| Metaverse Object Type | **Person** ||
| Link Type | **Join** ||
| Precedence | *Choose a number between 1 – 99* | 1 – 99 is reserved for custom sync rules. Do not pick a value that is used by another synchronization rule. |

5. Go to the **Scoping filter** tab and add a **single scoping filter group with two clauses**:

| Attribute | Operator | Value |
| --- | --- | --- |
| sourceObjectType | EQUAL | User |
| cloudMastered | NOTEQUAL | True |

Scoping filter determines which Azure AD objects this outbound synchronization rule is applied to. In this example, we use the same scoping filter from “Out to AD – User Identity” OOB synchronization rule. It prevents the synchronization rule from being applied to User objects which are not synchronized from on-premises Active Directory. You may need to tweak the scoping filter according to your Azure AD Connect deployment.

6. Go to the **Transformation** tab and implement the following transformation rule:

| Flow Type | Target Attribute | Source | Apply Once | Merge Type |
| --- | --- | --- | --- | --- |
| Direct | PreferredDataLocation | PreferredDataLocation | Unchecked | Update |

7. Close **Add** to create the outbound rule.

![Create outbound synchronization rule](./media/active-directory-aadconnectsync-change-the-configuration/preferredDataLocation-step5.png)

### Step 6: Run Full Synchronization cycle
In general, full synchronization cycle is required since we have added new attributes to both the AD and Azure AD Connector schema, and introduced custom synchronization rules. It is recommended that you verify the changes before exporting them to Azure AD. You can use the following steps to verify the changes while manually running the steps that make up a full synchronization cycle.

1. Run **Full import** step on the **on-premises AD Connector**:

1. Go to the **Operations** tab in the Synchronization Service Manager.

2. Right-click the **on-premises AD Connector** and select **Run...**.

3. In the pop-up dialog, select **Full Import** and click **OK**.

4. Wait for operation to complete.

> [!NOTE]
> You can skip Full Import on the on-premises AD Connector if the source attribute is already included in the list of imported attributes. In other words, you did not have to make any change during [Step 2: Add the source attribute to the on-premises AD Connector schema](#step-2-add-the-source-attribute-to-the-on-premises-ad-connector-schema).

2. Run **Full import** step on the **Azure AD Connector**:

1. Right-click the **Azure AD Connector** and select **Run...**

2. In the pop-up dialog, select **Full Import** and click **OK**.

3. Wait for operation to complete.

3. Verify the synchronization rule changes on an existing User object:

The source attribute from on-premises Active Directory and PreferredDataLocation from Azure AD have been imported into the respective connector space. Before proceeding with the Full Synchronization step, it is recommended that you do a **Preview** on an existing User object in the on-premises AD connector space. The object you picked should have the source attribute populated. A successful **Preview** with the PreferredDataLocation populated in the Metaverse is a good indicator that you have configured the synchronization rules correctly. For information about how to do a **Preview**, refer to section [Verify the change](#verify-the-change).

4. Run **Full Synchronization** step on the **on-premises AD Connector**:

1. Right-click the **on-premises AD Connector** and select **Run...**.

2. In the pop-up dialog, select **Full Synchronization** and click **OK**.

3. Wait for operation to complete.

5. Verify **Pending Exports** to Azure AD:

1. Right-click the **Azure AD Connector** and select **Search Connector Space**.

2. In the Search Connector Space pop-up dialog:

1. Set **Scope** to **Pending Export**.

2. Check all three checkboxes, including **Add, Modify, and Delete**.

3. Click the **Search** button to get the list of objects with changes to be exported. To examine the changes for a given object, double-click the object.

4. Verify the changes are expected.

6. Run **Export** step on the **Azure AD Connector**

1. Right-click the **Azure AD Connector** and select **Run...**.

2. In the Run Connector pop-up dialog, select **Export** and click **OK**.

3. Wait for Export to Azure AD to complete.

> [!NOTE]
> You may notice that the steps do not include the Full Synchronization step on the Azure AD connector and Export on the AD connector. The steps are not required since the attribute values are flowing from on-premises Active Directory to Azure AD only.

### Step 7: Re-enable sync scheduler
Re-enable the built-in sync scheduler:

1. Start PowerShell session.
2. Re-enable scheduled synchronization by running cmdlet: `Set-ADSyncScheduler -SyncCycleEnabled $true`

## Enable synchronization of UserType
Azure AD Connect supports synchronization of the **UserType** attribute for **User** objects in version 1.1.524.0 and after. More specifically, following changes have been introduced:

Expand Down
Loading