Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 4, Using msDS-SourceAnchor

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Green Fields Deployment with msDS-SourceAnchor

Following on from my previous sourceAnchor posts, let’s assume a new deployment with AAD Connect into an empty Azure Active Directory tenant.

I step through the AAD Connect setup wizard, adding the Forests from my lab (forest1.com and forest2.com), scoping sync to a single OU in each case (SyncOU) and choosing msDS-SourceAnchor as my sourceAnchor attribute –

I complete the wizard allowing initial sync to be triggered and wait … and wait … and nothing shows up in my Azure Active Directory tenant!

What’s Going On?

If you go back to Part 2 of this series, I demonstrated that msDS-SourceAnchor starts life as a NULL value. What this means is that sourceAnchor in the AAD Connect Metaverse is not populated when the default sync rules are used. I can see this by running

“C:Program FilesMicrosoft Azure AD SyncUIShellmiisclient.exe”

I then click on Metaverse Search and then the Search button which displays the objects imported from my Forests into the AAD Connect Metaverse –

If I double-click on one of these objects, I can see the attributes in the Metaverse that have been populated –

In this case, we cannot see sourceAnchor (I’ll discuss sourceAnchorBinary in a later post)

It follows that AAD Connect can’t create an object in Azure Active Directory. We’ll need to modify the sync rules.

Editing the Sync Rules

The sync rules editor is opened by running

“C:Program FilesMicrosoft Azure AD SyncUIShellSyncRulesEditor.exe”

When this opens, you’ll notice that the rules are filtered by Inbound and that for each Forest, there are three rules that relate to Users –

The rules for each Forest are

• In from AD – User Join
• In from AD – User AccountEnabled
• In from AD – User Common

We don’t have to touch In from AD – User Join

Modifying User AccountEnabled and User Common Rules

The process for modifying each of the other rules is exactly the same –

For each of

• In from AD – User AccountEnabled
• In from AD – User Common

Select a rule, click Edit and then click No when prompted to copy the rule

Click Next three times

On the Transformations page, scroll down until you see the Target attribute sourceAnchor

Change the source expression from

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor]))),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])))

to

IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([msDS-SourceAnchor]),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))),IIF(IsPresent([msDS-SourceAnchor]),IIF(IsString([msDS-SourceAnchor]),CStr([msDS-SourceAnchor]),ConvertToBase64([msDS-SourceAnchor])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))))

Click Save

If prompted with an Expression Warning, click Yes

For reference it may be easier to understand the code if viewed with formatting. Note that the following formatting should NOT be used in the expression box –

IIF(
	IsPresent([msExchRecipientTypeDetails]),
	IIF(
		[msExchRecipientTypeDetails]=2,
		NULL,
		IIF(
			IsPresent([msDS-SourceAnchor]),
			IIF(
				IsString([msDS-SourceAnchor]),
				CStr([msDS-SourceAnchor]),
				ConvertToBase64([msDS-SourceAnchor])
			),
			IIF(
				IsString([objectGUID]),
				CStr([objectGUID]),
				ConvertToBase64([objectGUID])
			)
		)
	),
	IIF(
		IsPresent([msDS-SourceAnchor]),
		IIF(
			IsString([msDS-SourceAnchor]),
			CStr([msDS-SourceAnchor]),
			ConvertToBase64([msDS-SourceAnchor])
		),
		IIF(
			IsString([objectGUID]),
			CStr([objectGUID]),
			ConvertToBase64([objectGUID])
		)
	)
)

Also understand that the conditions surrounding msExchRecipientTypeDetails are used to handle linked mailboxes in a Resource Forest and are implemented by the AAD Connect setup wizard (we want to keep them).

Creating a Rule to Write sourceAnchor back into msDS-SourceAnchor

Now we have rules that correctly populate sourceAnchor in the Metaverse, we need rules that write sourceAnchor back into the on-premises msDS-SourceAnchor attribute –

Change the rule editor filter to show Outbound rules

Take note of the precedence of the last rule in the list

Click Add new rule

On the Description page, set the Name to Out to AD – msDS-SourceAnchor

On the Description page, set Connected System to the Forest you’re currently configuring the rule for

On the Description page, set Connected System Object Type to user

On the Description page, set Metaverse Object Type to person

On the Description page, set the Precedence to a value higher than the precedence noted above (this will need to increase for each new rule created for each Forest)

Click Next three times

On the Transformation page, click Add transformation

In the new transformation set the FlowType to Direct, the Target Attribute to msDS-SourceAnchor, the Source to sourceAnchor and the Merge Type to Update

Click Add

Repeat for each additional Forest being synchronised

Close the rules editor

Trigger a Full Sync

Open a PowerShell prompt and execute

Start-ADSyncSyncCycle -PolicyType Initial

You should now find that users are successfully synchronised to Azure Active Directory and that sourceAnchor is written back into msDS-SourceAnchor for on-premises objects.

Conclusion

The rule changes configured here prefer msDS-SourceAnchor as the sourceAnchor source but use objectGuid when msDS-SourceAnchor is NULL. sourceAnchor is written back to msDS-SourceAnchor in the on-premises object so that this attribute is always used after the initial sync, even after a migration of the user object between Forests.