There’s been renewed interest recently in Teams Connect, the Shared Channels functionality announced at Ignite 2021 “Spring Edition” and then again at “Fall Edition”.
If you don’t know what Teams Connect is, I’ll explain briefly (or you can read this more detailed overview from Tony Redmond). It allows you to configure a Teams channel that is shared between different Microsoft 365 tenants, and appears almost natively in each, avoiding Guest IDs and Teams tenant switching.
Amongst IT consultants and fellow Microsoft MVPs who work across lots of different tenants there’s been some excitement, as folks are envisaging this will remove a lot of their day-to-day pain switching tenants. Personally, I don’t think folks working individually across with several clients will see the big benefits. The benefits come when larger groups need to work together.
Teams Connect, Shared Channels and the supporting Azure AD technology, Cross Tenant Collaboration (referred to at Ignite 2021 as B2B Direct Connect) are most suitable for use-cases where people outside of IT departments need to have longer, ongoing relationships as part of virtual teams. A typical use-case will be a large enterprise who works with an external marketing agency. Shared Channels will make it easy for them to spin up new campaigns, and then chat and work on files together.
In most cases, I’ll expect that IT departments will plan to use controls available in Cross Tenant Collaboration to make sure the right guide-rails are in-place. The model for Teams Connect is such that the business should be able to create new Shared Channels and add the right people quickly and easily. Therefore, IT departments will create the relationships in Azure AD Cross Tenant Collaboration with the right scoping between organizations up-front and then step back and let the business do as they need.
In many cases, this will be a model where one organization who owns the relationship will “host” Shared Channels, and then the partner organization will “join” or consume the Shared Channels. Rather than always creating a two-way relationship so shared channels can be created on both side, basic governance should follow wording within contracts to make sure it is clear in which tenant data should be stored, and then the configuration for that relationship created to make sure those guide rails enforce those rules.
The B2B Direct Connect model that underpins Teams Connect is perhaps as interesting – if not more interesting than Shared Channels. When this launches, according to information shared at Microsoft Ignite 2021 Fall Edition, you’ll see Cross-tenant access settings that will be used to create and manage the relationships.
For Active Directory veterans, the closest model to Cross Tenant Collaboration is an Active Directory External Trust. Relationships can be created between multiple Azure AD tenant, and rules for inbound access and outbound access created, along with tenant restrictions. Whilst we’re expecting defaults to be able to be configured (but access not enabled by default), it’s unlikely most medium to large organizations will want access to be wide open.
With rules in place, access cross-tenant is accomplished without Azure AD Guest access. You’ll still be able to use that – and keep that traditional model in place for orgs you don’t have a really close relationship with – but for the closest relationships, you’ll be able to allow people to access Shared Channels and other underlying services, like SharePoint Files using their source Azure AD ID. If you trust the org, you can even allow their Conditional Access rules to be respected – avoiding the need for a user to re-authenticate or set up Authenticator for accessing your tenant.
So – how does this help with complex migrations to Microsoft 365?
When I think about complex migrations – I don’t mean technically challenging. We’re at a point now with Microsoft 365 migrations where there are very few technical blockers due to messy source configuration or legacy tech. It’s possible, just a pain sometimes.
I’m thinking about complex blockers that mean that either a migration to Microsoft 365 isn’t possible, or that the experience once migrated will be counter-productive due to limitations that the organization’s compliance teams or external regulatory bodies might enforce.
There are very few organizations that can’t migrate to Microsoft 365 but there are many who could migrate to Microsoft 365 – but it will make collaboration harder once they move across.
What I’m seeing across private sector and public sector organizations – in particular private sector organizations who are working globally – is that those who haven’t migrated yet aren’t staying on-premises because they want to.
An example I’ve seen mirrored several times across organizations ranging from those with hundreds of employees to nearly a hundred thousand is a cast-iron need to limit the possibility of Global Admin access to individuals based in a particular country. That would be fine if they only operated in a single country, but unfortunately they’ll often operate globally and have the same requirement in several places.
This can’t be solved by a well-designed target operating model or Microsoft 365’s multi-geo features, and as such, this sizable minority of organizations have stalled in their plans to migrate, as they are in the small minority that (today) need multiple tenants.
On-premises today, those organizations will often have separate AD Forests in each region with their own respective implementations of Exchange and SharePoint Servers. AD Trust Relationships allow them to grant access to virtual teams working on projects. For many of these types of customers, most of their day-to-day working will already be benefiting from working as a global team and sharing knowledge and people on the majority of their projects. It’s just particular projects that have driven them to use a model that allows complete separation when needed.
Before Teams Connect and Cross Tenant Collaboration, that meant there was only one option: getting the right agreement in-place with Microsoft to allow them to use Azure AD Guest access cross-tenant without double-licensing users, and then working using Azure AD Guests when they work cross-tenant.
As you can imagine, that means that even with supporting technology in place, there’s still challenges such as Conditional Access and MFA Prompts and of course, Teams tenant switching.
Further complicating Azure AD Guest access is that if you are the type of organization that has these kind of complex requirements blocking your migration – using Azure AD Guest access for both day-to-day “internal” usage cross-tenant and your third-party guests leaves you in a messy situation as you might need to limit what third-party Guests can see and do.
This has therefore left that sizable minority of customers with complex environments in a position where they can’t migrate – as whilst technically they can move data and meet their customer’s requirements – they know that the experience for users would be miserable as they regularly have to switch tenants when working with colleagues.
Teams Connect solves a large proportion of the problem by allowing the equivalent of the AD Trusts to be put in place, with scoping, and with rules to determine who can share from where, mirroring the way they’ve been able to successfully work.
It doesn’t solve everything though. The challenges that still remain are likely to do so for some time; email domain sharing across tenants isn’t available today. Cross Tenant Collaboration features will, according to Microsoft, allow for searching based on email address, but won’t provide the ability to expose a common GAL or user picker. You’ll need third-party tooling in-place such as FIM plus third-party email gateways to provide a single email domain and GAL. But – for many organizations facing what had seemed a complex path to Microsoft 365, this might be enough. The devil will be in the detail – such as which compliance and retention features will be available at launch or soon afterwards, and when support for environments like GCC will be available.
