Ever need to change an Azure tenants user’s UPN from one of your verified to another? This needs to be done for a few reasons, but usually this is done to migrate people between departments / sub companies in cases where their email has changed. Unfortunately, ADConnect tries to do this, but fails. How do we fix this? #PowerShell!

The Challenge

After changing UPNs in the on-premises Active Directory, you would expect that the changes are synced into Azure. The source AD Connect rules are the same, the source anchor is the same, the UPN is unique, but you end up with an email that resembles the one below:

Error Email

** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments.

Hello mr.allanf@broadarc.com,

You can troubleshoot this issue by running the Directory Synchronization troubleshooter on the server that has Azure Active Directory identity synchronization tools installed.

The Identity synchronization tool batch run was completed on Thursday, 16 April 2018 18:13:17 GMT for directory broadarc [broadarc.onmicrosoft.com].

The following errors occurred during synchronization:

Tracking ID: a1ba786c-1234-4d29-bf42-8af9a52aab65

Thank you,

The Azure Active Directory Team

Do not reply to this message. It was sent from an unmonitored email account.

Deciphering the Email

If you notice in the email, it breaks the issue apart into 3 columns. The updated email login / UPN of the user, the error message that this Blog is addressing, and the Source Anchor, which is what I like to call the “glue” between AzureAD and the on-premises Active Directory.

If you change 1 or 2 UPNs and receive this error, it’s not too big of a deal because you’ve probably remembered what the original UPN was. If you ran a script or changed many, you probably have very little idea. This is where the glue comes into play. Luckily, it doesn’t matter what the existing UPN is in either AzureAD or Active Directory. Why? Well if you remember setting up AD Connect, you chose an attribute to be your Source Anchor. This attribute will have the same value in both directories.

Finding Your Source Anchor Attribute

There are two ways that I’ll talk about.

The GUI Way

Log onto the machine that runs AD Connect and open Azure AD Connect

1. Click Configure

   

2. Select View Current Configuration and Click Next
3. Scroll down to the Synchronization Settings
4. View the property value under Source Anchor

   

5. In the example, the Source Anchor property is the mS-DS-ConsistencyGuide

    

The #PowerShell Way

Log onto the machine that runs AD Connect. This machine will have the ADSync PowerShell Module installed. Execute the following 2 commands.

Connect-MsolService
Get-ADSyncGlobalSettingsParameter | Where {$_.Name -eq "Microsoft.SynchronizationOption.AnchorAttribute"}

The output of the 2^nd command will show you the Source Anchor that is used between your directories. Look at the “Value” property. In the case below, the Source Anchor is the mS-DS-ConsistencyGuid property.

Name                   : Microsoft.SynchronizationOption.AnchorAttribute
InputType              : String
Scope                  : SynchronizationGlobal
Description            :
RegexValidationPattern :
DefaultValue           :
Value                  : mS-DS-ConsistencyGuid
Extensible             : False
PageNumber             : 0
Intrinsic              : False
DataType               : String

Solving the Challenge

Well the issue with ADConnect and Azure AD is that it currently doesn’t like switching between custom verified domains.

Here is some simple PowerShell code to help resolve your problem. You could easily wrap this in a ForEach loop instead of doing it one by one.

To speed things up and not having to go directly to AzureAD for every fix I need, I just pull down all AzureAD users into one variable.

Connect-MsolService
$users = get-msoluser -All

This is where the fix comes in. We’ll do it one by one so you can follow the process.

1. First we’ll get the copy the Source Anchor from the first entry in the email into the clipboard
2. Replace the Source Anchor in the code below with the value from the clipboard
3. Now run the following 2 commands

$u = $users | where {$_.immutableId -eq "1CnF/RnI9Uyx0ofuAsnZTg=="}
$u

1. Verify that the output of the user in the “$u” command is the same user you want to work with
2. Now let’s fix the problem in AzureAD by switching the accounts UPN to the “default” OnMicrosoft.com domain, and then set it to the actual value we want it to have that matches the value in our on-premises ActiveDirectory.

Set-MsolUserPrincipalName -ObjectId $u.ObjectId -NewUserPrincipalName "123temporary123@broadarc2.onmicrosoft.com"
Set-MsolUserPrincipalName -ObjectId $u.ObjectId -NewUserPrincipalName "Laura.Lastname@broadarc2.com"

One issue I’ve run into when doing this is that I’ve found that sometimes the tenant already has a matching “onmicrosoft.com” account. This is why I use the 123tempoary123 email alias, as it probably won’t exist ?

I hope that helps!