Closed AaronL100 closed 5 years ago
@AaronL100 Thanks for your feedback! We will investigate and update as appropriate.
We are having the same issue. We used to remove users from local AD, sync, and then restore in 365 AD. The user would then show as "in cloud" for SOA and we could share mailbox, edit attributes, etc.
Now after restore in azure AD, the user shows "synced with active directory" and no changes can be made in 365. User has been deleted in local AD so we are stuck.
Previously we use to do hard match , can you please let us know if i have to match a user with a recovered user account(now after recovery account is in synced with ad state) how to proceed ahead. Only thing i can think is create a sync conflict and then fix with sycn health
It can take up to 30 days for the user to be permanently deleted. It basically goes into a delete queue where it is a soft delete pending 30 days, and then a final purge. How long has it been since you deleted the user/s?
CC: @eross-msft
@mchrislincoln describes the exact problem we're having. We're a higher education institution who is licensed to allow alumni to keep their email accounts for life. We need some way to break the sync and manage alumni accounts cloud only.
I had opened a support ticket before I saw this article and comment section. The guy I'm working with is telling me I need to export a PST for each mailbox, delete the account, then re-create and import the PST??? Surely this cannot be correct!!!!
@ttilton , your description of creating the PST and restoring is what I have seen as well. Whoever suggests this has obviously never done this on a 50gb mailbox. It would take weeks and probably break 10 times in the process!!!
I would reiterate that the process of deleting the account in local AD, syncing, and restoring in 365 to break the link worked great up until about 2 weeks ago.
Maybe MS is seeing too many shared mailboxes without exchange licenses?
For us, until this is fixed I am going to create another synced OU in local ad and call it "shared mailboxes" so we can still move old users somewhere, disable them and keep their email. This is a PITA to have them on the local AD though and should not be this way.
@ttilton , please reply if they give you a command or instructions on how to break the link.
@mchrislincoln I'll definitely share any new info I get! I just replied to the guy asking for clarification and letting him know that this is super inconvenient. We'll see what he says...
I can also confirm that this process was perfect and worked great up until about two weeks ago.
Hi @mchrislincoln , how long did you wait for the account to delete? Can you describe the exact change you see between how this worked before and how it works now?
Marilee, I don't think you understand the issue I raised initially. After Microsoft's change, Restored users in Office 365 are now unmanageable. These users are showing up as "Synched with AD", however, there is no AD account to sync with any longer. And, you get an error if you try to delete these accounts in the cloud. Is there a fix for this?
@AaronL100 being an ex-microsoft employee i may be able to help you. If u r looking to permanently delete the user either just let the user stay in soft deleted and it will get removed after 30 days or check this link on how to do that instantly https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-users-restore
Now for Admins who are trying to match the restored account to a different active directory account on prem like previously after restoration accounts use to be in "Incloud' now will always be in"synced with active directory" so all you can do is either stop the sync that willll convert all the users to incloud or u can simply do a soft-match (SMTP match) which is working and then u can change the UPN and other attributes. If u have any question let me know
@AaronL100 being an ex-microsoft employee i may be able to help you. If u r looking to permanently delete the user either just let the user stay in soft deleted and it will get removed after 30 days or check this link on how to do that instantly https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-users-restore
Now for Admins who are trying to match the restored account to a different active directory account on prem like previously after restoration accounts use to be in "Incloud' now will always be in"synced with active directory" so all you can do is either stop the sync that willll convert all the users to incloud or u can simply do a soft-match (SMTP match) which is working and then u can change the UPN and other attributes. If u have any question let me know
Thanks, @abhinavcarlsberg - that is correct.
We will now proceed to close this thread. If you have further questions please post to MSDN, tag us in the comments here, and we will continue the conversation and report to the product team as appropriate. https://social.msdn.microsoft.com/Forums/en-US/home?forum=WindowsAzureAD
I would not consider this closed at all. If you read what everyone is saying, WE ARE NOT TRYING TO MATCH TO A CLOUD ACCOUNT TO AN ACCOUNT IN LOCAL AD. We want to take an account that was synced to local ad and make it "In Cloud" so there is no connection for that account to local ad and then we can manage the account in the cloud.
I don't think "Stopping Sync" is a valid solution as I read it can take 72 hours to turn it back on.
Again, the goal here is to take a single account (not all of them) that is synced with local ad and break the sync so it exists in the cloud only.
I am in total agreement with @mchrislincoln this issue is absolutely not resolved. As an organization that provides alumni accounts, I have to make ~600 to 1000 accounts cloud only every year typically in large batches. The old process of making these accounts cloud-only worked well. It's going to take forever now for me to to export these psts and recreate the accounts. You need to either undo this change or provide an option within O365 to convert synced accounts to cloud only with PoSH support.
@mchrislincoln @tyler-tilton - as of the latest update from microsoft they dont have an update for single object SOA change feature but the can only change SOA for the whole tenant. Since i am also waiting for single object change feature to roll out will update the info as soon as i get it.
P.S - I am not representing microsoft here but its the fact that they have not yet roll out or may be developed a fix to convert a account into ' In cloud' yet . Whatever we use to do previously was actually a bug which is removed now and have caused so many problems for us and others. Waiting for the update from product group team i will update you guys here as soon as hear from the product group team .
@mchrislincoln @tyler-tilton you guys can try this in the mean while for one user it worked for me and successfully converted user into 'Incloud'. Let me know if it works for you guys - This requires either Global Admin or Contributor from RBAC settings to be able to access this feature. From the Azure portal, we will be able to go through a few steps to identify specific repairable scenarios:
I agree with @mchrislincoln this threat should not be closed, the change of this so called "bug" causes only issues while there was nothing wrong with the behavior in the first place.
Issues now: 1.) Unable to delete a restored user that was previously synced 2.) Unable to move users between different AD forests (multiple connectors in AADConnect) that are synced to one tenant. 3.) Unable to convert a synced user to a cloud managed user.
Stopping the sync on a 25K user tenant is not a acceptable solution for us.
IMHO this should be rolled back to what it was, there is no logic in restoring a deleted user to a synced account when there is no sync relationship to a local AD object anymore.
@abhinavcarlsberg I did some testing in my environment. First, I cannot remove synching for our entire tenant, so that's not an option. I did try to recreate the AD account to "soft-synch" with Office 365, then change the UPN to a different suffix. That did not work. The Office 365 account was still "synched with AD".
This is a Microsoft bug that needs to be fixed on their end.
@MarileeTurscak-MSFT I do not believe this issue to be resolved. Please re-open this thread. This has worked for 6+ years and needs to be resolved so that we can easily convert once-synced accounts to cloud only. This is a very important feature for our organization and others judging by this thread.
@MarileeTurscak-MSFT Please respond.
Thanks for the feedback. I am looking into this with the product team and will update the thread when I hear back.
@MSF-KRIS-OP "there is no logic in restoring a deleted user to a synced account when there is no sync relationship to a local AD object anymore" That's the point. This is a serious issue.
Thanks in advance for your help @MarileeTurscak-MSFT
ATTENTION EVERYONE!! Please visit Microsoft's user feedback website on this and request them to undo this change! https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36479119-allow-conversion-of-ad-synced-accounts-to-in-clou
@AaronL100 Would you be willing to speak with someone on the product team about this and provide more details about your use case? Please email me at AzCommunity@microsoft.com
@AaronL100 thanks for reaching out! I'll plan to join you in the call on Friday with the PG engineer. In case you need help sooner I would also recommend opening a technical support ticket for this issue. If you go through Github issues/forums we will help as much as we can but won't be able to see your setup so may not provide as quick of a resolution as someone from CSS might.
@MarileeTurscak-MSFT Any update on this?
Rob de Jong (Azure AD IAM) comentado · 18 de enero de 2019 01:44 · 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
I have checked it and it's working fine: restored users are now "In cloud" @MarileeTurscak-MSFT Thanks a lot for your help.
Great news everyone - based on your feedback the product team decided to revert the bug fix that caused the issue (see above comment).
Thanks for your persistent feedback and efforts to get this issue resolved.
We will now proceed to close this thread.
After migrating a user to cloud only. Then joining that users machine to Azure AD. I run CMD whoami and I’m showing a return value of previousDomain/username, and not AzureAD/user like I would if the user was created in AzureAD/O365.
It seems like the tenant still believes the user is hybrid or mastered outside the cloud.
Is this a bug? Im trying to do a full cloud only migration and this was very unexpected and I’m worried that issues might arise. Does this matter? Is there a way to correct this?
So, Office 365 users that were synced with AD, then deleted from AD, then restored in Office 365 are now showing up as "Synched with AD." The account no longer exists in AD, and it gives you an error if you try to delete the user in Office 365 (because it's a synched account). Why was "In Cloud" incorrect? How do you fix this for these accounts now?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.