Understand how to safely change from a troublesome custom source anchor to a system managed source anchor by preparing a staging server with updated configuration, populating existing anchor data and cutover.
Hello everyone, this is David Loder again, with a topic from a recent customer interaction that was a repeat of a topic I’ve seen several times over the years. That’s my cue to write a blog. This is for the customers who were trying to be consistent with their data governance but ended up making operational problems for themselves with a poorly chosen Connect Sync source anchor.
Where I’ve typically seen this problem is with customers that have a strong data governance program and a governance rule that states something like ‘employees are represented in all systems by their employeeID.’ For expository purposes I’ll use employeeID throughout this discussion, but it applies equally to any HR-owned business-focused attribute. This governance stance unfortunately leads the customer into choosing employeeID as their source anchor for Entra Connect Sync instead of the default system-managed selection.
Side note: read The False Identifier Anti-pattern for insight from Pamela Dingle about a protocol standards viewpoint of how to represent accounts in different connected systems.
At the beginning, this choice of employeeID for source anchor appears to be fine. All their users get synced up to Entra without issue. Then they start migrating to Exchange Online, and they hit their first problem. To migrate a generic mailbox, they discover the user for that generic mailbox isn’t present in Entra because it doesn’t have an employeeID. So, they develop a process to generate fake employeeIDs. Everything again runs fine for a while. Then they hit a rehire scenario where HR messes up the employeeID by accidentally giving them a brand new employeeID. HR later discovers that mistake and updates the employeeID back to its original value from the first time the person was an employee. Or it was a contract-to-employee change, and the person goes from their fake employeeID to a real one. All these scenarios end up causing problems, manifested as sync errors, solely due to an HR-owned business-focused attribute like employeeID being the source anchor.
Do any of those scenarios sound familiar? I only see a small percentage of our customers. But I’ve seen this challenge multiple times, so I know there are others who have been living with these problems.
This discussion will walk you through a process to safely switch over to a new, system-managed source anchor, while preserving the source anchor value for all current users. This allows you to return the HR-owned business-focused attribute like employeeID solely back to its original data governance intent. We will no longer have to struggle with the challenges of both HR and IT overseeing an immutable source anchor. What makes this possible is the fact that Entra doesn’t care what attribute is your source anchor. What Entra cares about is that the source anchor for each user is immutable – that it is unique and unchanging. Once set, it no longer matters where it came from. Entra doesn’t really know it’s an employeeID – it’s just a collection of bytes.
What is my current source anchor?
How do you know if you’re running a custom source anchor? Here are some places where that choice is exposed.
Open the Connect Sync setup wizard, select View or export current configuration, and you’ll see the selected source anchor under Synchronization Settings.
You can export the configuration and review the JSON file. You’ll find it in the identityMappingPolicy.
"identityMappingPolicy": {
"azureSourceAnchorAttribute": "employeeID",
"userPrincipalNameAttribute": "userPrincipalName",
"userMatchingPolicy": "AlwaysProvision"
}
You can run this PowerShell command to get the source anchor:
(Get-ADSyncGlobalSettingsParameter | Where-Object Name -eq 'Microsoft.SynchronizationOption.AnchorAttribute').Value
employeeID
You can query the beta onPremisesSynchronization graph API using Graph Explorer or another method. You’ll find it in the configuration.
GET BETA https://graph.microsoft.com/beta/directory/onPremisesSynchronization?$select=configuration
{
"@odata.context": "https://graph.microsoft.com/beta/$metadata#directory/onPremisesSynchronization(configuration)",
"value": [
{
"configuration": {
"anchorAttribute": "employeeID",
"applicationId": "1651564e-7ce4-4d99-88be-0a65050d8dc3",
"synchronizationClientVersion": "2.6.84.0",
"synchronizationInterval": null,
"customerRequestedSynchronizationInterval": null,
"accidentalDeletionPrevention": {
"synchronizationPreventionType": "enabledForCount",
"alertThreshold": 500
}
Finally, you’ll find the default source anchor flow in the default “In from AD - User AccountEnabled” and “In from AD - User Common” rules. That flow is this expression, and it contains the chosen sourceAnchor attribute in many of the function calls:
IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF("employeeID"="mS-DS-ConsistencyGuid",IIF(IsPresent([employeeID]),IIF(IsString([employeeID]),CStr([employeeID]),ConvertToBase64([employeeID])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))),IIF(IsString([employeeID]),CStr([employeeID]),ConvertToBase64([employeeID])))),IIF("employeeID"="mS-DS-ConsistencyGuid",IIF(IsPresent([employeeID]),IIF(IsString([employeeID]),CStr([employeeID]),ConvertToBase64([employeeID])),IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))),IIF(IsString([employeeID]),CStr([employeeID]),ConvertToBase64([employeeID]))))
Approach for changing source anchor
There are two fundamental tasks that a source anchor selection must accomplish. First, there must be a globally unique (and immutable) value calculated as the source anchor value for each user. Second, there needs to be an attribute where that unique value is stored.
For selecting a unique value, we desire to move back to the default Connect Sync behavior which uses objectGUID as a unique value that was already automatically created by AD. For storing that unique value, we want an unused extension attribute. Because the extension attributes are string syntax and objectGUID is binary, we’ll follow the default Connect Sync behavior and base64 encode objectGUID before storing it. Choosing an extension attribute for storage is also a good choice because the existing employeeID source anchor is likewise a string syntax. We need to use an attribute with the same syntax to handle the existing values for existing users.
For this discussion I’ll illustrate moving from employeeID to msDS-cloudExtensionAttribute5, but this will work for most any choice of attributes. I picked one of the cloud extension attributes to hold the new source anchor because they’re newer and less likely to already be in use. The cloud extension attributes also don’t have a default outbound sync flow so there is less export data to analyze for cutover. I’ll show later why that’s important.
In case you were hoping to be able to move fully back to the Connect Sync default of objectGUID and mS-DS-ConsistencyGuid as the default source anchor value and storage attributes, we unfortunately can’t make it all the way back to those defaults. Connect Sync doesn’t provide all the conversion functions we might need, but more critically, base64 encoding can’t be reversed for arbitrary string values. For example, a reasonable employeeID of ‘9001004’ as a source anchor value is not a valid base64 string and thus cannot be the base64 encoded output of any binary input.
For existing users, I’ll show how we’ll copy the current source anchor values into the new source anchor storage attribute of msDS-cloudExtensionAttribute5. For brand new users, we’ll take their objectGUID, base64 encode it, then save it to msDS-cloudExtensionAttribute5 as their source anchor value.
We’re going to use a staging server instance to orchestrate the change and eventually take over for production after proving that it won’t make any breaking changes.
A word of caution here. Trying to change source anchor without a solid understanding of what you’re doing can be dangerous. Microsoft’s standard disclaimer applies to this process I’m discussing here. Fortunately, by following the process I describe, you’ll be able to prove you’re ready for change control. We’ll be able to show all the existing users continue to have their same source anchor, and that the staging-mode Connect Sync is going to make literally zero changes to your tenant, prior to making any production cutover.
Another caution. Ensure your current Connect Sync is running error-free before starting this process. Because we’ll be swapping to a parallel staging-mode Connect Sync, any data errors already causing sync problems on your production Connect Sync will negatively impact the new staging instance. Those errors require extra data analysis, making it harder to prove that you’re ready with a zero-impact change. A while ago I provided advice about managing staging servers and our current staging server docs are now very comprehensive. Be sure you understand the architecture for staging servers and why you want to have zero sync errors before starting this process.
We’ll start with the staging server running in a coexistence mode. During this phase it will be entirely subservient to the production Connect Sync. It will batch up changes needed to publish the existing anchors into the new attribute. Because we’re switching source anchors, it will have a slightly different config than production to accommodate the switch. Synced users who already exist in the tenant will maintain their source anchors with exactly their same existing values. Since source anchor must be immutable, we absolutely cannot change that source anchor value for any user. However new users after the cutover will have source anchor values taken from the system default objectGUID. This introduces an epoch where existing users have an anchor that matches their employeeID and is recognizable as that value. Users created after the epoch will have an anchor that is the base64 value of their objectGUID and will appear as just a random string of characters. Your human admins will notice the difference in the pattern, but neither Connect Sync nor your Entra tenant will care. To switch between the two different configs, there will be a small set of config changes made to the staging server at cutover time.
Install new Connect Sync staging server
The existing Connect Sync server has the data we need to start moving the source anchor, but most customers have change control processes that prevent making changes to an active production instance. So, we’re going to use a new staging server for populating the existing source anchors into the new, unused, extension attribute. We’ll also use it for showing that it will make zero changes to our tenant at cutover time, greatly minimizing the risk of the change.
On the existing Connect Sync server, open the Microsoft Entra Connect Sync setup wizard, select View or export current configuration, then Export Settings and save the JSON export file.
Earlier we discussed the very complex source anchor expression for the “In from AD - User AccountEnabled” and “In from AD - User Common” rules. If you look at the JSON export file, you’ll see both those rules are present, but the details are absent. In my lab, with default rules, the content of the User AccountEnabled rule is just this simple, being basically only a reference to its internal immutableTag:
{
"Name": "In from AD - User AccountEnabled",
"uniqueIdentifier": "6f6ca816-39c3-4281-8caa-6ceb34df64e2",
"immutableTag": "Microsoft.InfromADUserAccountEnabled.009",
"precedence": 102
}
You’ll also notice the only reference to our current employeeID source in the JSON export file is in the previously mentioned identityMappingPolicy.
"identityMappingPolicy": {
"azureSourceAnchorAttribute": "employeeID",
"userPrincipalNameAttribute": "userPrincipalName",
"userMatchingPolicy": "AlwaysProvision"
}
The reason for the complexity of the source anchor expression is that any chosen source anchor needs to successfully work within the same expression pattern. Therefore, the only place where our source anchor exists in the config export is in the identityMappingPolicy.
CAUTION: If you do happen to notice that your source anchor attribute name also appears in the customSynchronizationRules section, then you need to be sure you fully understand what is happening with your custom rules and potentially your source anchor attribute. While the remainder of this discussion will include verification to prove we’re not going to break anything, I can’t speak to the intent of what a custom rule for those default flows is attempting to accomplish. But that’s also the main reason for doing this work on a staging server – so we can validate the new configuration without impacting production.
In the JSON export file, in the identityMappingPolicy section change the azureSourceAnchorAttribute from the existing custom source anchor to the new attribute you want to use going forward.
Note: The attribute name being placed into azureSourceAnchorAttribute is case sensitive. Copy the name from Active Directory Users and Computers (ADUC) Attribute Editor tab for a user to ensure the attribute name is properly formatted.
On the new Connect Sync staging server, go ahead and run the setup. To be able to import the config, you must choose the Customize option, not Express. We’ll mostly be following the docs for installing Connect Sync on a staging server. I’ll call out the few points to which I want you to pay special attention.
On the Install Required Components screen, select the options appropriate for your environment, but also select Import synchronization settings and browse to config file you just updated which now contains the new source anchor attribute name.
Continue through the rest of the wizard and on the Ready to configure screen, unselect Start the synchronization process when configuration completes, while ensuring Enable staging mode is selected. As we’ll be making a change to our existing rulesets to orchestrate the source anchor migration, there’s no reason to start syncing just yet.
Configure Connect Sync Staging Server for Coexistence
So far, we’ve accomplished one main task: the new staging server is configured to use your replacement custom attribute as its source anchor. The first problem to start solving is that the new attribute is empty in AD and obviously doesn’t match the existing source anchors for the existing users.
We’ll start with a temporary rule that exports the existing source anchor values from employeeID in the metaverse into the new source anchor msDS-cloudExtensionAttribute5 in AD.
Open the Synchronization Rules Editor, change Direction to Outbound and select Add new rule. Create the rule like this example:
Description section
Name: TEMP Out to AD - User Current Source Anchor
Connected System: select the AD forest
Connected System Object Type: user
Metaverse Object Type: person
Link Type: Join
Precedence: unused value in the custom rule range 1-99
Transformations section
Add transformation: FlowType=Direct Target=msDS-cloudExtensionAttribute5 Source=employeeID
With this new rule in place, open PowerShell and run an initial sync cycle with this command:
Start-ADSyncSyncCycle -PolicyType Initial
Review initial AD update
Once the initial sync is done, you should be able to see the pending exports for AD. Open the Synchronization Service Manager, select Connectors, highlight your AD forest connector and select Search Connector Space from the Actions menu. Change Scope to Pending Export, turn on Add, Modify and Delete then click Search. You should see all your in-scope AD users listed.
If you click into the properties of one of the users and sort by the Changes column, you should see a Pending Export add for your new source anchor attribute.
If you have a large environment and want to perform a thorough review of the pending exports there’s a two-step command line to generate a CSV of the pending exports. We first generate an XML document of the pending exports by running csexport.exe with syntax of "csexport.exe MAName ExportFileName /f:x". After generating the XML document, we convert it to CSV using the CSExportAnalyzer with syntax like "CSExportAnalyzer ExportFileName.xml > %temp%\export.csv".
This is an example from my lab of how to create the pending exports CSV:
C:\Program Files\Microsoft Azure AD Sync\Bin>csexport.exe "logon.loderdom.com" c:\temp\adexport.xml /f:x
Microsoft Identity Integration Server Connector Space Export Utility v2.6.84.0+bd41d5baef33ccdf6e1c8e7e892837c3cba1cbfd
Copyright c Microsoft Corporation. All rights reserved.
[3/3]
Successfully exported connector space to file 'c:\temp\adexport.xml'.
C:\Program Files\Microsoft Azure AD Sync\Bin>CSExportAnalyzer.exe c:\temp\adexport.xml > c:\temp\adexport.csv
Remember I cautioned earlier about correcting sync errors first. Sync errors can pollute the export queue with data about exports unrelated to our source anchor change. Or if you have a very active environment there can also be transient data changes that make analysis difficult. My prior blog covered both topics to help with a pending export analysis.
If you’re happy with the pending export data changes sitting in the AD connector pending export queue, you can run the Export profile for the AD connector to write the current source anchor values into AD. The command syntax is "Invoke-ADSyncRunProfile -ConnectorName <Connector Name> -RunProfileName Export". In my lab the example command looks like this:
Invoke-ADSyncRunProfile -ConnectorName 'logon.loderdom.com' -RunProfileName Export
Yes, even though this is a staging server, it is quite capable of writing data if you tell it to do so. Staging mode simply never runs the Export step during the scheduled cycle. Be very cautious about using this power. Absolutely do not try to export the Entra tenant connector. This staging server isn’t yet fully ready to take over for production, so exporting the Entra tenant connector could change your production tenant in unintended ways – up to and including deleting data. Performing a thorough analysis of the Pending Export queue on a staging server is paramount to ensure it’s only going to make the intended changes. You’ve been warned.
Once the export is complete, run a Delta cycle with this command to confirm the export:
Start-ADSyncSyncCycle -PolicyType Delta
If you encountered export errors, ensure the AD connector’s service account has write permissions for the new attribute.
Congratulations, we’ve completed the second main task. Existing users now are getting their source anchor values saved into the new source anchor msDS-cloudExtensionAttribute5 field. Run a Delta cycle followed by an export of just the AD connector as a batch and you’ll catch up to production again each time that runs. This is a coexistence mode we can run in for as long as we want.
Default Filtering for the Staging Server
There is one main difference we need to address when changing from using employeeID as a custom source anchor to using the base64-encoded objectGUID as the source anchor value. You’ll find the difference in the Outbound “Out to AAD - User Join” rule. If you view that rule and look at the Scoping filter section, you’ll see there’s a default filter for sourceAnchor ISNOTNULL. This filter is the reason you had to create fake employeeIDs to bring a generic user account into sync scope.
Part of the benefit of moving off employeeID as the source anchor is that we will no longer have to formulate fake employeeIDs to get users without a valid employeeID to sync. The downside is that we’re no longer able to rely upon employeeID to be the flag that controls which users sync and which users don’t sync. Every user automatically has an objectGUID, so the effectiveness, or burden, of having the source anchor also acting as a filter no longer applies. You may view this as a good or bad change.
If the filter was a burden, and making up fake values, or dealing with uniqueness problems with your old source anchor was a problem, you’ll likely be happy with change. Just be prepared to ensure your OU selections are appropriate. If you had an overly-inclusive OU selection and were inadvertently relying on source anchor filtering, you probably will need to reassess your OU selections for the staging server. Again, later in the document, I’ll walk us through a review of the staging server to help ensure that the in-scope user population matches production.
If the old source anchor filter was an important part of your provisioning logic, then you likely want to reintroduce that logic with a custom rule. Otherwise, the staging server will want to start provisioning users that production skipped. To add employeeID back as a required field, we need to add an Inbound custom rule that acts upon the cloudFiltered clause of the Outbound “Out to AAD - User Join” rule. CloudFiltered is another default filter that prevents provisioning when cloudFiltered is True. This allows us to still change our source anchor yet keep employeeID as now just a triggering flag instead of also being the immutable source anchor. An example rule for using cloudFiltered when employeeID is empty looks like this:
Description section
Name: In from AD - User Filter employeeID ISNULL
Connected System: AD forest
Connected System Object Type: user
Metaverse Object Type: person
Link Type: Join
Precedence: unused value in the custom rule range 1-99
Scoping filter section
Add group, add clause: Attribute=employeeID Operator=ISNULL
Transformations section
Add transformation: FlowType=Constant Target=cloudFiltered Source=True
You can add an additional scoping filter clause if you want to narrow such a rule down to specific OUs, such as an example clause like "DN contains ,OU=HRFeed,". That allows you to use both OU inclusion and required attribute filtering to keep your user scope from shifting during this migration. Review Microsoft Entra Connect Sync: Configure filtering for more discussion on filtering.
Preparing for Cutover
There will be two validations we’ll perform in preparation for cutover during change control. If either validation fails, we can abort the cutover process and simply allow the current production Connect Sync to keep running. We can then work through what’s wrong with the staging server configuration and retry.
Note: If you are using federation to authenticate with Entra, the federation server is already flowing a claim for immutable ID sourced from your anchor attribute. Because we’re changing which attribute holds the anchor value, you’ll need to coordinate with your federation team to update the configuration with the new attribute (msDS-cloudExtensionAttribute5 instead of employeeID). You can review Microsoft Entra Connect - AD FS management and customization for examples of the ADFS claim rules. Though your ADFS is likely only using something like rules 1-3 currently as there’s no fallback with a custom source anchor. Help them prepare for a coordinated change control process after all the validation steps have completed.
Pre-Cutover Validation
While we’re running in our coexistence mode our source anchors are coming from the existing process for employeeID. We don’t expect much difficulty in this phase. To verify everything is working as expected, on the staging server, run a few more Delta cycles with exports for the AD connector. Then check the pending exports for both the AD connector and the Entra tenant connector.
Open the Synchronization Service Manager, select Connectors, highlight your AD forest connector and select Search Connector Space from the Actions menu. Change Scope to Pending Export, turn on Add, Modify and Delete then click Search. By this time, we should have reached a steady-state and there should be zero pending exports. Repeat for the Entra tenant connector and verify there are also zero pending exports for the Entra tenant connector.
Having zero pending exports is one goal to show our data and rules are aligned and this Connect Sync server has no data it wants to change in the Entra tenant. If there are pending exports present, and they’re not due to in-flight transient data, you should delay the cutover while you determine why this staging server wants to export data that production did not already export.
Our next check is to validate that the Entra tenant connector has zero disconnectors. Or that it has a disconnector population that matches production. Ideally, it’s the zero disconnectors case. Disconnectors are objects in Entra that were previously synced by some other instance of Connect Sync but are not being managed by this staging Connect Sync instance. Again, my prior blog included a discussion on disconnectors.
Open the Synchronization Service Manager, select Operations, highlight the most recent Delta Sync operation for your Entra tenant connector. In the Synchronization Statistics section, review the Disconnector count. Ideally, it’s zero on the staging server and also zero on current production. If it’s a non-zero number, export your disconnectors and determine why they aren’t being managed. Are the objects old and orphaned and should be deleted? Or is something else wrong with your syncs? One note, if you’re already using Cloud Sync for its disconnected forest feature, objects synced that way show up as disconnectors, increasing the difficulty of a disconnector review for Connect Sync.
Zero pending exports for both connectors on the staging server and zero disconnectors for the Entra tenant on both staging and current production is our goal for pre-cutover validation. If you’ve reached that state, you’re ready to proceed into change control. You have the evidence that the new Connect Sync has no data that it wants to write and proof that all objects in the tenant are properly connected. Otherwise, be prepared to explain your non-zero counts to the change control board.
Cutover
We’re now ready to move the staging server from its coexistence mode into production. First, stop the scheduler on the current production Connect Sync with this command:
Set-ADSyncScheduler -SyncCycleEnabled $false
Next, back on the staging Connect Sync server, run one final Delta sync cycle and AD connector export so that it is completely caught up with all the production changes. This ensures the final set of source anchor values used by the production instance employeeID rule have been written to our new source anchor attribute.
Then, we’ll make three changes to replace our temporary outbound source anchor rule with the rules we need for production operation.
Open the Synchronization Rules Editor, change Direction to Outbound, select the TEMP Out to AD - User Current Source Anchor rule and Disable it.
We’ll replace this temporary outbound source anchor rule with one very similar to the default rule that is created when ConsistencyGuid is the chosen anchor. It will writeback the verified source anchor into our custom source anchor storage attribute. In the Synchronization Rules Editor, stay on Outbound, select Add new rule, and create a rule that looks like this:
Description section
Name: Out to AD - User ImmutableId
Connected System: AD forest
Connected System Object Type: user
Metaverse Object Type: person
Link Type: Join
Precedence: unused value in the custom rule range 1-99
Transformations section
Add transformation: FlowType=Expression Target=msDS-cloudExtensionAttribute5 Source=IIF(IsPresent([cloudSourceAnchor]),[cloudSourceAnchor],IgnoreThisFlow)
The second rule we need is an Inbound rule very similar to the default rule already being used to populate sourceAnchor. The default rule is hardcoded to calculate sourceAnchor from ConsistencyGuid with fallback to objectGUID, but that behavior triggers only when ConsistencyGuid is the chosen source anchor. We’ll need to make a custom version with similar behavior for our custom source anchor.
In the Synchronization Rules Editor, change Direction to Inbound and select Add new rule. Create the rule like this example:
Description section
Name: In from AD - User sourceAnchor
Connected System: AD forest
Connected System Object Type: user
Metaverse Object Type: person
Link Type: Join
Precedence: unused value in the custom rule range 1-99
Transformations section
Add transformation: FlowType=Expression Target=sourceAnchor Source=IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([msDS-cloudExtensionAttribute5]),[msDS-cloudExtensionAttribute5],ConvertToBase64([objectGUID]))),IIF(IsPresent([msDS-cloudExtensionAttribute5]),[msDS-cloudExtensionAttribute5],ConvertToBase64([objectGUID])))
After making these three rule changes on the staging server, run another Delta cycle, but do not run any exports. Because of the rule changes, the scheduler will automatically perform a Full Sync step on the AD connector. Be prepared for the time that might take in your environment during change control. The earlier full syncs should give a reasonable estimate of how long a full sync of the AD connector should take.
Once the Delta cycle finishes, we need to perform one final review of the pending exports. Again, the idea scenario is that there are zero pending exports for both the AD and Entra tenant connectors. If there are pending exports, evaluate that they seem reasonable given your churn-rate during the time sync has been offline. This is the point where any missing filtering rules will show up. You may see pending export user adds for users that are now passing the default filter because of their automatically calculated source anchor value when you did not intend for those accounts to become synced.
If you need to back-out the change, that’s as simple as re-enabling the scheduler on the production Connect Sync with this command:
Set-ADSyncScheduler -SyncCycleEnabled $true
Then, on the staging server you can disable the two new rules and re-enable the “TEMP Out to AD - User Current Source Anchor” rule to go back to the coexistence state and figure out what additional changes are needed.
However, if you’re happy with what’s present in the pending exports and are ready to proceed, take the staging server out of staging mode and into production mode. Rerun the setup configuration wizard, select the Configure staging mode option, uncheck Enable staging mode, and on the Ready to configure page check Start the synchronization process when configuration completes and click Configure.
As mentioned before, if you are federated, this is now the time to have your federation team update the source of their immutable ID claim to use the new source anchor attribute msDS-cloudExtensionAttribute5 instead of the old employeeID attribute.
As a post-cutover validation test, create a new user. After the first Delta cycle completes you should see the new user in both the Connect Sync metaverse and in your Entra tenant. Their source anchor (Entra portal labels it “On-premises immutable ID”) should be their base64 encoded objectGUID. In text form it will be similar to this example, looking like a random string instead of their employeeID:
Ppw0iMRaDkWCZ6S3JIIaxg==
After the second Delta cycle, that source anchor value should be written back to the new source anchor attribute msDS-cloudExtensionAttribute5 in AD.
Summary
That was quite a journey to fix a fundamental mistake likely made years ago. I helped you see how to take a source anchor that was previously inappropriately tied to HR and IT business processes and move it to a dedicated system-managed process. We orchestrated that movement with Connect Sync in staging mode to provide a long coexistence path. And we empirically proved, ahead of change control, that we would be introducing a very low risk change to the environment.
Hopefully you found this to be an interesting discussion. And especially if you are admin for an organization who thought they were trapped by these processes, I’ve given you confidence in a roadmap to improve your sync posture.
Thanks for spending a little bit of your time with me.
-Dave
Disclaimer: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Microsoft