Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts

MVP

Hi

 

We have currently setup a ADConnect Sync to Office 365, this is working well.

 

We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advise or does anyone know how we might approach this? Or can point to alternative resources?

 

We need to ensure the accounts in Office 365/Azure AD remain active and usable.

 

Much appreciated

Paul

 

62 Replies
I haven't opened a ticket; I'm not sure if this is a supported methodology. The shared mailboxes though that I have stopped syncing still have not disappeared. I am not ready to declare victory yet in my pilot. My verdict will be posted Monday. Its looking good so far though.

We have a configuration where we can exclude the accounts from syncing by populating an attribute with the term "noSync."  You should be able to achieve the same thing though by putting these accounts in to a non syncing OU.  Excluding the accounts from any exposure to sync seems to be a key element.

I ran a re-homed a very large group of shared mailboxes over the weekend.  Every single AD account made native in Office 365  was successful!  I had no accounts disappear.  They are all fully editable.  In short, the did exactly what I wanted them to do.

In short my process looks like this.

  1. I stop the ad account from syncing (move to a non replicating OU.)
  2. After I have verified it is not longer visible in Office 365  (Get-MSOLUSER,) I run..

Get-MsolUser -UserPrincipalName <user UPN> -ReturnDeletedUsers |Restore-MsolUser

     3. I follow this with:

Set-MsolUser -UserPrincipalName <user UPN> -BlockCredential:$true

 

This is pretty easy to do in bulk.  My last step will be to remove the non replicating AD accounts.

 

I raised a ticket with this with MS, the support engineer suggested nulling theImmutableId like this (or piping any number of deleted users in):

 

Get-MsolUser -UserPrincipalName foo@domain | Set-MsolUser -ImmutableId ""

 

That was suggested by someone above in the thread and seems to work fine. I also asked him to escalate it internally which he said he would.

 

Although this might not be a supported way of doing things I would think it's still quite common. We often have people here who leave and then we need to keep their mail hanging about for months or even longer so other people can see it. Rather than keeping the user in AD or messing about with PST files I can now leave them in the cloud until they're no longer needed which is a good solution :)

I've been working on this today and it looks like you can't null out the ImmutableID until the user has been deleted and restored.  So I'm removing the accounts from the synced OU, run the sync, confirm deletion with

 

Get-MsolUser -ReturnDeletedUsers

 

When all accounts that are being converted show I then run this.

 

$DeletedUsers = Get-MsolUser -ReturnDeletedUsers
foreach ($user in $DeletedUsers) {
Restore-MsolUser -UserPrincipalName $user.UserPrincipalName
Set-MsolUser -UserPrincipalName $user.UserPrincipalName -ImmutableId ""
}

After doing this with a small scale test, accounts did not get deleted after subsequent syncs. 

 

This process of changing the ImmutableId in the cloud directly is not supported and it was available due to a bug in Azure AD. As of today, this has been fixed and so it's no longer possible to update the ImmutableId or change the source or authority to "Cloud-only", unless you disable DirSync on the whole Tenant. There's a new feature in AAD Connect called "Update SourceAnchor" that will change AAD Connect's source anchor configuration from ObjectGUID to ms-Ds-Consistency-GUID attribute which will allow you to manage the Immutable's  value in local AD, instead of having to change it in the cloud with Set-MsolUser.

"The SourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this option is read-only. If you need to change this setting, then you must uninstall and reinstall."

 

I cannot find ANY documentation which suggests what is "Supported" and what is not.

 

The goal is to convert an AD Synced user to a Cloud user WITHOUT having to stop AD Sync for ALL Users. [which seems like burning down the house to kill a spider]

Used to just move user to a non-synced OU, run a Delta sync, then restore user from deleted users, and it was then an "In Cloud" user.

Now when that is done, it restores the user back to "Synced with Active Directory."

 

Some have mentioned this was able to be done due to a bug, which has been patched.

IS there an "Easy" way to convert 1 user to a Cloud User?

 

Hello,

Is there any documentation of this correction ?

Maybe it was a bug by Microsoft BUT many of us used this 'bug' from years !

this is a huge change I was doing it for many years also !

Thanks,
Yousef

I have a ticket open with the Azure AD Cloud Identity team and they confirmed this as well.  Being able to change the ImmutableID on a restored account was "fixed (no longer possible)" starting in December for our tenant.  I was still able do this via the Azure AD V2 modules but that route is going to get "fixed" soon as well.  The only documented option I saw for Hybrid users was to do a New-MailboxRestoreRequest to copy content from the deleted mailbox into an empty mailbox.  This is less than ideal because of the time required to do mailbox restore vs just re-linking an Azure AD account.  I am still waiting to see what they propose as a solution now that they are no longer allowing changing the immutableID for identities that were originally sourced from On-Prem AD.

Confirmed this in my own tests. Once the user is "on-prem managed", you can not anymore modify the immutableId using Set-MsolUser command.

 

However, I managed to do this by disabling the sync, resetting the immutableId to "" and then enabling the sync again. If you have massive number of users, and/or need to do this just once, this could do it for you. But this is quite "heavy" to do on daily basis.

Hi Nestori

 

Thanks for you feedback. We're a "sluggish" +100k user shop with presents in over 130 countries with one tenant, one Global Forest (2 ADs) and several (+40) ADs "synced" via MIM. MS told us to disable the sync for the complete tenant but like you say, with several mutations a day, this is going to be a nightmare. We're still in contact with MS so they provide us with some guidance on a possible, working, workaround.

 

Regards

 

Jan

Jan, I would really like to know the updates regarding your ticket with MS once you have them! Thanks in advance 

There's now a release note regarding this change at:

What's new in Azure Active Directory?

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#novemberdecember-2018

 

This helps explain the background reasons for Microsoft having to fix this bug. The main thing to keep in mind is that, unfortunately this bug was giving the wrong impression that accounts synchronized from AD were 'converted' to cloud-only accounts, when in reality this 'trick' was just flipping one simple DirSyncEnabled flag and keeping all the main synchronized properties of the object. The Office 365 portal showed the accounts as "Cloud-only" because it was only looking at the DirSyncEnabled flag. So the 'trick' was not really converting anything at all in first place. 

 

 


@Paul Bullock wrote:

Hi

 

We have currently setup a ADConnect Sync to Office 365, this is working well.

 

We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advise or does anyone know how we might approach this? Or can point to alternative resources?

 

We need to ensure the accounts in Office 365/Azure AD remain active and usable.

 

Much appreciated

Paul

 



Okay.., Let me try this one and then I will give you some feedback

We have the same issue and received the same info from Support that nulling the immutable is not longer supported and they consider it a fix. the suggested uservoice to get it changed.  there is already a posting on uservoice for this https://office365.uservoice.com/forums/312601-office-365-admin-mobile/suggestions/36380371-feature-r....

 

Please vote it can't hurt.

Anyone can share the latest steps (step by step) on how to do this with the current change?

There is also a feedback request on Azure.com which we can vote on - not sure which one will get their attention to actually change this back:

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36479119-allow-conversio...

Import-Module Azure
$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
Set-MsolDirSyncEnabled –EnableDirSync $false
(I answered ‘y’ when prompted)

<Wait until you stop getting the ADSynced user warning in the O365 portal when you go to edit a username>

Set-MsolUser -UserPrincipalName test.user@example.com -ImmutableID ""

<Wait 10 minutes>

Set-MsolDirSyncEnabled –EnableDirSync $true
(I answered ‘y’ when prompted)
<This last step will take 6-8 hours-ish before sync restarts>