Jamie Luce, I'm sorry but that scenario is not possible.

If I understood correctly, you want to make resource rooms cloud-only so that you can authenticate directly to Office 365 (Azure AD). The authentication (managed/federated) is defined per domain, so despite that users can be cloud-only, the authentication remains the same. 

However, you can give these resource rooms (users) another domain (resource.domain.com etc.), which is not federated. Then give them an alias with original domain. With this scenario, you could sync them from on-prem AD and still use the original domain to reserve rooms.

For the AD-removal-deletion issue, I think you need to do the following:

1. Remove the user from AD (or move to OU that is not synced)
2. User gets deleted from Azure AD -> restore the user
3. Change UPN to @domain.onmicrosoft.com
4. Clear the immutableId and run the sync (or wait until it is run)
5. Set immutableid to something unique, such as user's email address
6. Change UPN back to original

Nestori Syynimaa We have some resource rooms that need to be licensed and have a password, but the Resource Manager that we use cannot handle Multifactor Authentication.  We had these rooms syncing from on prem before but now we just need them to be cloud to take them out of Multifactor (Ping Federate).  We are creating all new Resources as cloud accounts directly but we didn't want to lose the info on the ones we were already using, so we deleted the AD account on prem, then restored it as a Cloud Account.  

Then ran into the sync problems with it being removed since it still thought it was a deleted account.  I'm interested in those instructions if you could PM them to me.  Thanks

Jamie Luce, I'm not quite sure why you need to convert federated users to in-cloud, as they are (typically) synchronized from on-prem AD and are depending on the federation server?

Anyways, there can also be cloud-only federated users, so you can change the UPN back to domain.com. You just need to give immutableId that matches the value your federation server is offering for the user when he/she logs in.

So, this is possible but not very practical and needs some setup to do in your federation server. If you'd like to give it a try, let me know and I'll give you detailed instructions.

Jamie Luce I don't think you can set the immutableID to null unless it is a managed domain so that is likely why you can't change back to federated.  

Maybe try https://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin/matching-on-premises-user-to-cloud-user/f2a52719-24d2-4436-a257-fc3e60714c65 and see if that fixes it

crice011 We are getting an error "You must provide a required property:  Paramet name:  FeeratedUser.SourceAnchor"  So we have to set the domain to a managed domain domain.onmicrosoft.com then we can set the ImmutableID to Null, we can't change it back to the domain.com after.  

Thats good news...!

It is working. I did so last night with 2 users. They were successfully converted to Azure AD users (cloud users) that used to be sync'd from on-prem by nulling the ImmutableID

I did log a ticket with MS last few weeks ago, they also said they will revert back the changes. I am wondering if they already did?

Anyone can confirm it is now working again? (I am too lazy to test..LOL).

Jessie_Hernandez seems to be answering to a totally different thing than what was asked. Yes, you can link the existing Azure AD user to a different on-prem AD user using the ms-DS-consitencyGUID attribute. But you cannot use it to make users cloud-only (which was the original question).

The method suggested by RedRobot works, because you can change the ImmutableId when the sync is not enabled. However, this is a very heavy method if needs to be done daily. But as said, it works.

I thought everyone else said -ImmutableID does not work anymore?
Can anyone confirm this? Or have you tried this?

We ended up switching our Azure AD Connect Source anchor from Objectguid to ms-DS-consistencyGUID (as recommended by Support).  This works for us because it allows us to recover deleted accounts via hard linking to on-prem AD accounts.  Before we would control this by manipulating the immutableID of the Azure AD user.  Now we just manipulate it on the on-prem AD side.  Here is blog post which illustrates this process: https://blogs.technet.microsoft.com/latam/2018/03/27/using-the-consistencyguid/

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>

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-conversion-of-ad-synced-accounts-to-in-clou

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

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-rollback-users-should-become-incloud-once.

Please vote it can't hurt.

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. 

I will!

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

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

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.

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 https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/delete-or-restore-mailboxes 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.

Hello,

Is there any documentation of this correction ?

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