Alias in the cloud not synced with On Premises

  • Article

Hello All,

Here is another random issue. A user's alias on premise is not synced with the alias in the cloud. You try to run a few delta syncs, and even a full sync but the alias wont sync up. You can't update the cloud object using Set-mailbox or Set-msoluser, so what is next?

Well lets first start with what happened. Thus far, I have ran into two possible causes here.

First, when the user account was provisioned, the alias that was on premise was invalid. Perhaps an extra space, or a period at the beginning or end of the mailnickname attribute on premise. For the mailnickname attribute, it cannot start or end with a period, as well as must be a unique value. If it is not a unique value, AAD Connect will still sync the user object however it was manually update the attribute to allow the user object to successfully sync. As of result of O365 creating the mailnickname attribute itself, O365 is now the originating authority for the attribute. Therefore subsequent syncs from AAD will not look to sync this attribute.

The second source for this may be an administrative change. For example, a colleague knows about the Set-AzureAD cmdlets and manually updated the object in the cloud. Now another admin has the task of fixing the attribute but doesn’t know how. An admin can use this to update both synced with AD or cloud only objects. Nevertheless when you use this cmdlet for an object synced with OnPremise, you are changing the originating authority of the attribute. This means O365 owns the authority of this attribute as opposed to your on premise AD server, thus will not look to sync the attribute in subsequent syncs, unless the attribute itself is specifically changed.

The best way to resolve this issue depends on where the user account exist. If the broken account is a cloud only account then you can simply use the Set-AzureADuser cmdlet to update the mailnickname attribute. If the object is syncing from an AD account on premise, then you will need to physically update the alias on premise to force AD Connect to pick up the change and sync that to the cloud. Next go back and update the object again, and force the final sync to the cloud.

First we will go through the steps for the quick method. You can use a Set-AzureADuser cmdlet to update the object in the cloud. Steps 1 through 7 goes through the necessary steps to upgrade your Powershell application, and import the necessary modules to run the appropriate cmdlets.

  1. Open Powershell as an administrator
  2. You will need to be running the lastest powershell version which is 5.1.
    1. Type this cmd in powershell to determine your current version. $PSVersionTable.PSVersion
    2. Click this link to upgrade.
      1. connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
      2. You may need to install WMF 5.0 to install the new powershell versions. The Prereqs are here. You may need to install WMF 5.0 to install the new powershell versions. The Prereqs are here. https://msdn.microsoft.com/powershell/gallery/readme
  1. Install the Azure AD Module
    1. Install-Module -name AzureAD
  • Import-Module AzureAD
  • Connect-AzureAD

 

    1. [Enter O365 admin credentials]
    1. Run this cmdlet to get the information for the AzureAD user. This will show you when the "alias" is currently set to. The attribute used for "alias", is mailnickname.
  • Get-AzureADUser -SearchString user@domain.com | fl userprincipalname,mailnickname,objectID

 

  1. Run this cmdlet to update the user with the new desired mailnickname attribute.
    1. Set-AzureADuser objectID [insert objected] -mailnickname [enter new mail nick name].

In the event the user object is synced from on premise Active Directory, then the easiest way to resolve the issue is to update the mailnickname object on premise and sync that to the cloud. For example if the user's alias was Sarahjo, change her alias on premise to SarahJo1. This will force AD connect to recognize the attribute change, and upon the next sync cycle the user is O365 will have an alias of Sarahjo1. Now your on premise servers are the source of authority for the attribute again, and we can go back on premise and change to alias to what you want it to be. Update the object on premise again and run a final delta sync to sync the correct alias to O365. Follow steps 8-13.

    1. Update the mailnickname attribute on premise. For example if its set to “Sarahjo”, change it to “Sarahjo1”.
    2. Run an Ad Sync cycle to sync the change to O365.
  • Start-ADSyncSyncCycle -PolicyType delta

 

    1. Run the cmdlet from step 3 above to verify the mailnickname attribute changed.
    2. Change the mailnickname to what you want it to be, I.e. “Sarahjo”
    3. Run another Sync cycle to sync to O365.
  • Start-ADSyncSyncCycle -PolicyType delta

 

  1. Confirm issue is resolved.

More Information: I am not a scripting expert, but here are a few one liners that may help you get things moving.

Use this cmdlet to collect an output of on premise AD users and their current mailnickname attribute.

 

Get-ADUser -Filter * -Properties mailnickname | Sort-Object -Property mailnickname -Descending | ft name,mailnickname,UserPrincipalName > ADusers.log

 

This can be used to collect a list of O365 Azure AD users mailnicknames. You may be able to expand the results, however I have not been able to find a solution to get

Get-AzureADUser -Top 500000  | ft UserPrincipalName,mailnickname