Setting the ImmutableID to $null

Here’s a small Friday afternoon snippet of useful information for all you Office 365/Identity nerds out there.

If you have converted an AAD user from ‘Synced with Active Directory’ to ‘In Cloud’ and you want to sync a new user object with that user, you will need to clear the ImmutableID and then match it up with the new user object. I’m planning on creating a more extensive post on that very subject in the near future, but for now, I’ll give you this titbit of information:

Clearing the ImmutableID is done using the Powershell command:

Set-MSOLUser -UserPrincipalName -ImmutableID "$null"

You might think that those quote marks are a bit pointless, but you would be wrong! If you were to run the command as shown below, without the “” marks, it wouldn’t show you an error, but it also wouldn’t actually clear the ImmutableID.

Set-MSOLUser -UserPrincipalName -ImmutableID $null

As with all things PowerShell, syntax is everything!


6 thoughts on “Setting the ImmutableID to $null

    • Not clear what you are trying to achieve. Do you try to match an on-prem account with an O365 account? If so, then you can set the ImmutableId property on the cloud account to match the on-prem account. The ImmutableId property doesn’t exit on-pre, It is derived from the on-prem user’s ObjectGUID parameter. You can use the script at to obtain the ImmutableId for a given on-prem user. Then you can set the cloud user’s ImmutableId to this value and tyou can be sure that DirSync will link the two and your cloud user will sync from on-prem.

      However if you don’t want to link a cloud account with an on-prem account (you want to leave it in-cloud) then your best bet is to move the on-prem account out of the scope of DirSync. I assume you scoped DirSync (more precisely, AAD Connect these days) to a select list of OUs. If you just scoped it to the entire AD forest then you’re in for a more extensive filtering exercise. You have two options in this case:
      1. Reinstall DirSync and scope it to relevant OUs.
      2. Configure filtering based on object property values. For instance if CustomProperty10 has a value of O365 then it will be synched. Otherwise it will not.

      The space here is not enough to give you detailed instructions, you have to google it. A good starting point is to search for articles on o365 object matching.

      Again, it isn’t clear from your post whether matching objects is a good or bad thing, and what is that you actually try to achieve.


  1. Robin says:

    Great stuff. Really helped.

    One thing I found. If you’re getting the error “You must provide a required property: Parameter name: FederatedUser.SourceAnchor” on O365,
    then chances are you need to set your UPN to your “*” address, clear the ImmutableID, then change the UPN back.

    Easy way to do this in powershell is to use the command:

    Set-MSOLUserPrincipalName -UserPrincipalName “” -NewUserPrincipalName “”

    Then follow Miss Tech’s guide. Then change the UPN back.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s