This is a reasonably specific case, but I thought it was kind of interesting. When we first started piloting Teams we were in Islands, just like everyone else. At that point people set up Teams, some of which had guest users, and everything worked just fine. Then, as part of the migration, I switched the Org-Wide default to SfbWithTeamsCollab, and then started moving users over to TeamsOnly. One of the consequences of this is that none of the guest users could chat with our internal users anymore, even those that were converted to TeamsOnly.
As it turns out, the Org-Wide upgrade mode dictates whether guest users can chat inside a guest tenant. Sure, there’s a setting in the admin center (Guest Access, Messaging, Chat), but if the tenant default is SfbWithTeamsCollab, it doesn’t have any effect.
To get out of this situation, I needed to change the default, but without changing the state of any of the users that hadn’t been migrated yet. Of course, you can’t just run Grant-CsTeamsUpgradePolicy with SfbWithTeamsCollab, since Teams will stop you from doing something redundant. The way around this though, is to note that there are actually two policies:
Note that one has the notification flag, and one doesn’t, so I could just iterate through the users with a $null policy assigned, and manually grant SfbWithTeamsCollabWithNotify to them. Once that was done, I changed the global default, accepted the scary warning that we’d now be TeamsOnly, and fixed guest access chat.
Again, I have no idea whether this is going to be a problem forever, and it smells like a bug to me, but at least in September 2019, this is still the way things behave. Fortunately, there’s a way around it, and it also has the benefit of letting you move users to Teams by just removing a per-user policy instead of assigning one. Might have been nice to know this BEFORE starting to move users, but that’s why I’m publishing this. If it helps someone avoid the same issue (or at least fix it)-mission accomplished!