Nov 11 2021 08:18 AM
We do not have a test environment so cannot test this. What actually happens after running this script?
I wish this could be run by user so I can see exactly what it's doing first but applying this to all 150 users at once causes some pause for sure.
The majority of our devices are still "authenticated" to our local AD, however, since they have not been in the office and we do not use VPN, they are all disconnected anyway. Our plan is to authenticate to Azure, but we need their account to first be cloud-only.
I have tried moving an account to a non-sync'd OU, which does break the connection, however, the user shows up in Deleted users and we have to restore them. That's all fine, however, Microsoft Teams does not work anymore and has issues connecting. Add to that ALL the user's private channel memberships are wiped and not restored so it's a massive headache doing it this way.
Any ideas on how we can do this by user?
Nov 11 2021 04:39 PM
Hey, Mercedes.
You might want to look at hybrid-joining your devices to AAD before cutting off the sync process. That may be a challenge given you've said they're all disconnected, implying they're frequently away from the office, but it's worth considering as a more incremental adoption process.
The process you've already used (filtering out, restoring) is the closest approximation to cutting over but comes with a significant gap around group memberships. You can use it for validating direct user account scenarios such as the password being the same but anything governed by group memberships will be lost. This soft deletion + recovery process also results in numerous deprovisioning and re-provisioning activities which may account for some of the Teams issues you've noted.
Again, unfortunately, there's no way (currently - and that I know of unless I've missed a more recent development) around these caveats meaning the "real" experience isn't something you can directly replicate.
As a quick final note on AAD passwords, they do remain unaffected by the cutover but it always pays to check if password synchronisation was ever enabled in AAD Connect, as in a federated environment, this may not necessarily be the case (since authentication is passed over from Office 365 to the AD FS - or whatever alternative - service). If it is not enabled then you might want to consider enabling it and adopting an enforced password reset transitional phase to ensure AAD accounts have the same passwords as their on-prem "masters".
Nov 12 2021 06:40 AM
@LainRobertson Thank you for your response. We are first disconnecting the device from the local domain then joining to AAD before we convert to the account cloud-only. That has been very smooth so far with no issues. Since we cannot do this for all devices/employees at once (we do not have the resources to do so), we needed to do this one by one by one.
The passwords from our local AD server do sync to Azure as currently if a user is still set to Dir Sync Yes in AAD we have to reset their passwords on the local AD.
I've contacted both O365 support and purchased support from Azure as well and no one can us a straight answer instead of "run the script and hope for the best" type of reply.
If running this script causes the same issue that I had with one user where they lose all of their private channel membership and now have 150 users to manually have to fix, we will not be able to run our business. We are heavily on Teams now and it's a scary situation to not have anyone at Microsoft able to help or guide us.
I can't even get a single powershell script to export all private channel memberships from Teams (I've tried 10+ ones I've found online but they only seem to work if you run it by each team/channel combo by name).
Nov 12 2021 10:04 AM