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 emily@misstech.co.uk -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 emily@misstech.co.uk -ImmutableID $null

As with all things PowerShell, syntax is everything!

16 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 https://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1 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.

      Like

      Reply
  4. 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 “*.onmicrosoft.com” address, clear the ImmutableID, then change the UPN back.

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

    Set-MSOLUserPrincipalName -UserPrincipalName “joe.bloggs@domain.com” -NewUserPrincipalName “joe.bloggs@acc.onmicrosoft.com”

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

    Like

    Reply

  5. Great tip! Follow-up: If you are trying resync a previously synced tenant, you can clear the immutableID of all cloud users before configuring AzureADConnect to the new AD so it matches by email\UPN. Otherwise, you will end up with two accounts, one in cloud and one representing the AD account.

    Like

    Reply
  6. Dan Warwick says:

    Here is a challenge for you: This method works excellently for Users, but can you find a way to do this for a Distribution Group…?
    So far all my migration methods involve Delete – AAD Sync – Recreate as cloud only group.

    Like

    Reply
  7. Anonymous Tech says:

    Hello! I know this post is old, but apparently one can no longer set the ImmutableID to null value. It was a bug this whole time that’s been fixed recently:

    “As per our communication we would like to inform you that the command to delete the immutable id is not in function as it is not supposed to run successful by design, however it was working before due to some issues.”

    If you try to run it now, you receive this message:
    “Set-MsolUser : Unable to update parameter. Parameter name: IMMUTABLEID.”

    Seeing if anyone has come across this yet with alternative solutions.

    Like

    Reply
  8. theBo77 says:

    Looks like Microsoft agreed, that this would be a usefull feature…
    (https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36479119-allow-conversion-of-ad-synced-accounts-to-in-clou)

    Rob de Jong (Azure AD IAM) comment 2018/01/18
    Hi folks –

    I’m happy to get back to you with good news: based on customer response we decided to revert the bug fix that caused the issue you were seeing and this should now be fixed.

    Our apologies for any inconveniences this may have caused and thanks for your feedback here and working with us to get this resolved.

    Thanks,

    Rob

    Like

    Reply
  9. Adam says:

    Amazing that this isn’t noted anywhere on Microsoft’s documentation. Was struggling to understand why this wasn’t working for me. Useful article even 6 years later!

    Thanks 🙂

    Like

    Reply

Leave a comment