Capture and Redirect Shared Channel Membership Requests

I must admit to being a tad bemused when I read MC635987 (July 11, 2023) on the topic of “capturing requests to use shared channels.” According to Microsoft, the feature will “provide a way for organizations to capture and redirect requests for external collaboration when users attempt to add an external member to a shared channel where B2B direct connect cross-tenant trust has not been mutually configured between the two organizations.” That’s quite a mouthful and it’s not easy to understand.

Parsing things out, the new feature breaks down into displaying and defining a web page for channel owners to go to when they run into problems adding a new member because the domain the member belongs to is not covered by the organization’s cross-tenant access policy. In this case, no trust exists between the two organizations. A tenant-wide setting defines the web page for users to visit if the access check fails and they wish to request support. Ideally, the web page should contain full tenant-specific instructions for how to request the organization to create a trust with the other organization.

Microsoft expects to deploy the update to commercial tenants in early August and complete rollout soon afterwards.

Shared Channels and Trusts

Shared channels depend on trusts between the tenant hosting the channel and the tenants where channel members come from. You can use PowerShell to discover which tenants shared channel members come from for shared channels hosted by your tenant or track access using sign-in logs.

The cross-tenant channel policies that enable the trusts are defined in the External Identities section of the Microsoft Entra admin center. Trusts must be two-way. In other words, it’s not enough for your tenant to trust the Contoso domain: Contoso must trust your tenant too before shared channels can work. An organization can have an open cross-tenant channel policy, meaning that it’s open to connections from any other tenant. Given the recent demonstration of how attackers could exploit external access to compromise Teams, this is not a good idea. It’s more work, but also more secure, to define cross-tenant access policies for each organization you want to collaborate with.

When a Cross-Tenant Access Policy Doesn’t Exist, Shared Channels Don’t Work

Which brings us to the problem Microsoft is trying to solve. Channel owners don’t know (much) about cross-tenant trusts and probably don’t know if a policy exists for a given external tenant. When they go to share a channel with a user, that person might not be able to access the channel because of the lack of trust. The new code check detects when the condition occurs and presents the user with a link to use if they need additional support (Figure 1).

The link can be to any URI (even if it points to a non-existent page). The link is defined in the Teams section of the Teams admin center. Go to Teams settings and scroll to the options for Shared channels. Set the “Provide a link to my support request page” to On and input the page link (Figure 2).

The page won’t create a cross-tenant access policy (remember, the policy must exist on both sides). It can gather information from the channel owner about why they want to collaborate with people from the target domain to allow administrators to decide if it’s appropriate to create a cross-tenant access policy. The administrators will also need to contact the administrators of the target domain to arrange for them to trust your domain.

Maybe a Guest Account is a Better Idea?

If the administrators decide that they don’t want to trust the target domain, the option still exists to create a guest account for the person and add them to a private channel (shared channels don’t support guest accounts). That is, if the B2B Collaboration policy allows accounts from that domain to join your tenant as a guest. There’s always something that gets in the way.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

Use Inbound and Outbound Shared User Profiles to Reveal the Ins and Outs of Membership in Teams Shared Channels

In August 2022, I discussed how to use the Get-AssociatedTeam cmdlet to report the membership of channels in teams for users within a tenant. It’s a useful cmdlet that includes the ability to report membership of shared channels in other tenants. In most cases, the reports that can be generated from the data returned by the Get-AssociatedTeam cmdlet meet the needs of administrators to know what channels users access.

Microsoft 365 often offers multiple ways to report data. In this instance, Azure AD supports shared user profile resources created for use with Azure AD B2B Direct Connect, the underlying cross-tenant access mechanism for shared channels.

• An inbound shared user profile represents an Azure AD user from an external Azure AD tenant whose profile data is shared with your tenant. The profile data is used by applications like Teams to display information about the inbound user in shared channels.
• Conversely, an outbound shared user profile represents Azure AD users from your tenant who share their profile information when they access resources in other Azure AD tenants.

Essentially, when a shared channel owner invites an external user to become a member of the channel and that user confirms their acceptance, Azure AD creates an inbound shared user profile to note this fact. Azure AD creates an outbound shared user profile when a user from your tenant becomes a member of a shared channel hosted by another tenant. For example, Figure 1 shows the membership of a Teams shared channel. The users marked with (External) have inbound shared user profiles.

Using PowerShell to Report Shared User Profiles

The Microsoft Graph PowerShell SDK contains cmdlets to fetch information about unbound and outbound user profiles. With consent for the CrossTenantUserProfileSharing.Read.All permission, you can connect to the Graph and run these commands:

Connect-MgGraph -Scopes CrossTenantUserProfileSharing.Read.All
Select-MgProfile beta
Get-MgDirectoryOutboundSharedUserProfile

UserId
------
08dda855-5dc3-4fdc-8458-cbc494a5a774
5b52fba5-349e-4624-88cd-d790883fe4c4
a221d10f-e0cf-4a1d-b6a2-4e844670f118
cad05ccf-a359-4ac7-89e0-1e33bf37579e
eff4cd58-1bb8-4899-94de-795f656b4a18

The output is a list of identifiers for Azure AD user accounts, so it’s not very exciting. IApart from not listing account names, the output doesn’t tell us what outbound tenants are accessed. To get that information, we must run the Get-MgDirectoryOutboundSharedUserProfileTenant cmdlet for each account. The output of that cmdlet is a list of tenant identifiers, which we can resolve to discover the tenant name. Here’s the code:

[array]$Users =  Get-MgDirectoryOutboundSharedUserProfile | Select-Object -ExpandProperty UserId
ForEach ($User in $Users) {
   $UserData = Get-MgUser -UserId $User
   [array]$TenantNames = $Null; $TenantDisplayNames = $Null
   [array]$TenantIds = Get-MgDirectoryOutboundSharedUserProfileTenant -OutboundSharedUserProfileUserId $User | Select-Object -ExpandProperty TenantId
   If ($TenantIds) {
       ForEach ($TenantId in $TenantIds) {
         $Uri = ("https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='{0}')" -f $TenantId.ToString())
         $ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get  
         $TenantNames += $ExternalTenantData.DisplayName
       }
       $TenantDisplayNames = $TenantNames -join ", "    
   }
   Write-Host ("User {0} has outbound shared profiles in these tenants {1}" -f $UserData.DisplayName, $TenantDisplayNames)
}

User Sean Landy has outbound shared profiles in these tenants o365maestro
User Ken Bowers has outbound shared profiles in these tenants o365maestro
User Tony Redmond has outbound shared profiles in these tenants o365maestro, Microsoft Community & Event Tenant

Getting Inbound Shared User Profiles

The Get-MgDirectoryinboundSharedUserProfile cmdlet lists information stored about inbound shared user profiles. We can’t read Azure AD to find information about these users because they come from other tenants. This is what the cmdlet returns:

Get-MgDirectoryinboundSharedUserProfile | Format-List

DisplayName          : Alex Wilber
HomeTenantId         : 22e90715-3da6-4a78-9ec6-b3282389492b
UserId               : a6453657-2058-4c15-a38a-b0a94f0ed737
UserPrincipalName    : AlexW@o365maestro.onmicrosoft.com
AdditionalProperties : {}

Once again, we can resolve the tenant identifier to make the information more understandable:

[array]$Guests = Get-MgDirectoryinboundSharedUserProfile
ForEach ($Guest in $Guests) {
    $Uri = ("https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='{0}')" -f $Guest.HomeTenantId.ToString())
    $ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get  
    Write-Host ("User {0} comes from tenant {1}" -f $Guest.DisplayName,  $ExternalTenantData.DisplayName)
}

User Christina Smith comes from tenant CM Portal Solutions
User Nicolas Blood comes from tenant NBConsult
User Alex Wilber comes from tenant o365maestro
User Tom Jones comes from tenant o365maestro
User Vlad Bitton comes from tenant vNext Solutions

The interesting thing here is that I didn’t recognize some of the user names and tenants that Azure AD stored inbound shared user profiles for. However, given that the names were all MVPs and my tenant supported many beta versions of Teams shared channels in the past, it’s entirely possible that the profiles originated in a test. Azure AD doesn’t register a date to tell you when it created a profile, so there’s no clue from that source.

Tracking External Access to Teams Shared Channels

My previous article describes how to create a report about the users accessing shared channels in your tenant. The added piece of information covered here is finding the set of Azure AD accounts from your tenant who use Azure AD B2B Connect to access resources in other tenants. That’s a valuable nugget if you want to track who’s interacting with Teams shared channels externally.

Create an Organization-Wide Communication Channel

When Microsoft delivers a feature like Teams shared channels, it can take some time for an organization to figure out how to use the new capability. This is especially true when external collaboration is in the mix. It’s sometimes easier to start to use a feature within the tenant before expanding it to accommodate external access.

One way to use shared channels is as an organization-wide communication channel. For example, the IT Help Desk could have a shared channel for users to ask questions (or maybe a set of shared channels to split questions up over different technologies). In this scenario, the channel owners must share the channel to make it available to users, so the question becomes how best to share a channel with large numbers of users.

Teams Shared Channels and Org-Wide Teams

You can share a channel with a team, and if your organization has fewer than 10,000 accounts, you might use org-wide teams to take advantage of their automatic membership management capabilities. Sharing a channel with an org-wide team sounds like an excellent way to make a channel available to everyone, but Teams doesn’t allow this to happen. When you got to share a channel with a team, org-wide teams are excluded (Figure 1).

A shared channel can be shared with up to 50 other teams.

Teams Shared Channels and Dynamic Teams

Dynamic teams are supported for shared channel membership, so you could create a dynamic Azure AD group with a filter to find all licensed user accounts (Figure 2) and team-enable the group. The downside is that dynamic Azure AD groups require Azure AD Premium P1 licenses, which might or might not be an issue for the organization.

DIY Membership Management via PowerShell

The alternative is to create your own shared channel membership mechanism. This is easily done with PowerShell, but only if you can keep the number of direct members of a shared channel to under 5,000 (including any teams you share the channel with). This is considerably less than the current 25,000 member limit for a team. Theoretically, you could share a channel with 50 teams, each having 5,000 users, to achieve wider coverage in a very large organization (I have not tried this). In this scenario, Microsoft cautions that real-time updates for shared channel content are “only available to 25,000 users at a time,” meaning that some users won’t get updates as quickly as others do.

Microsoft hasn’t said if they will raise the limit for direct membership of shared channels in the future but given previous history and the need to service some very large customers, it would be no surprise if they did.

In terms of populating the membership of a Teams shared channel with PowerShell, the task is straightforward:

• Identify the set of user accounts (with Teams licenses) to add to the shared channel.
• Find the current membership and owners of the shared channel.
• For each of the input set, check if they are a member. If not, add them.

In a script written to test the principle of how to populate the membership of a Teams shared channel (available from GitHub), I:

• Connect to Microsoft Teams and the Microsoft Graph PowerShell SDK.
• Use the Get-MgUser cmdlet to find the set of users with licenses (this avoids accounts created for room accounts, etc.).
• Filter out any accounts we don’t want to add to the shared channels. For instance, you might decide that you don’t want to add accounts holding administrative roles like global administrators because these accounts should not be used for day-to-day user tasks. I use a simple filter against the Office location property.
• Check each account to make sure that it has a Teams license that is enabled. Teams is included in many different Microsoft 365 products, so we check each account using the Get-MgUserLicenseDetail cmdlet to make sure that the Teams service plan is successfully assigned. See this article for more information about Azure AD license management using PowerShell.
• Use the Get-TeamChannelUser cmdlet to get the current channel ownership and membership and store the information in a hash table.
• Compare each user in the array of accounts with Teams licenses against the current shared channel membership and add any missing accounts with the Add-TeamChannelUser cmdlet.

Now on to Scheduling

The advantage of doing something like this with PowerShell is that you have full control over the membership of the shared channel. The disadvantages are the need to update and maintains scripts over time and to make sure that the script runs regularly to pick up new accounts. Azure Automation seems like the right way to schedule the script, but that’s another day’s work.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Team Owners Might Not Know Shared and Private Channels Exist

A post by Philip Worrell highlights a potential impact on those who own or access shared channels in archived teams. The same problem exists for private channels, and its origin lies in the fact that team owners are not, by default, members of private or shared channels and therefore have no idea if these channels are active. Let’s plunge into the details.

Archiving Teams

Archival is intended to be part of the natural lifecycle of teams. Once a team serves its purpose, its owners can archive it to put the team into a read-only state. Optionally, the SharePoint site belonging to the team can also be made read-only. Team members can access archived teams, but only to read information. Team owners can continue to update content in the team (and its site).

In archived teams, private and shared channels become read-only along with the channel sites. This is what you want: it would be strange to have regular team channels read-only while shared and private channels remain writable.

According to Microsoft’s documentation, when a team owner archives a team, it moves to the hidden teams section of the teams list. My experience is that this action is inconsistent for the team owner as often the archived team doesn’t show up in the hidden list. However, moving to hidden does seem to work for team members. When you restore an archived team, it always goes back into the hidden list, even some users had it as a featured team. I guess that it’s hard for Teams to figure out where a restored team should appear.

The Problem of Channel Visibility

Shared and private channels are owned by the team member who creates them (other owners can be added later). If they create shared or private channels, team owners know that these channels exist, but unless they become a channel member, they have no visibility into the channel. It might be that nothing happens, that no one participates in channel conversations or works on documents stored in the channel site. On the other hand, the channel could be very busy with frequent and ongoing contributions from tenant and external members. The point is that team owners don’t know what’s going on.

When the time comes to archive a team, the team owner can perform the action from:

• The Manage teams section of the Teams desktop or browser client.
• The Teams section of the Teams admin center.
• Using the Set-TeamArchivedState cmdlet from the Teams PowerShell module.

Archiving through the Teams desktop client doesn’t give an owner visibility into channels. As Figure 1 shows, even if the owner is a member of the team, unless they are a member of the channels, they see only regular channels listed for the team.

The Teams admin center option (Figure 2) tells the administrator that shared and private channels are present. They can then examine the properties of the channels to find out who the owners are and check in with the channel owners to discover if it’s OK to proceed with archiving.

To find channel information with PowerShell, you:

• Retrieve the group identifier for the team with Get-Team.
• Retrieve the list of channels for the team with Get-TeamChannel.
• Check the membership of the channels with Get-TeamChannelUser.

For example:

$GroupId = (Get-Team -DisplayName "Rugby Lovers").GroupId
Get-TeamChannel -GroupId $GroupId | Format-Table Id, DisplayName,MembershipType

Id                                                           DisplayName       MembershipType
--                                                           -----------       --------------
19:2bd93bd207a544c98457589df77c8dd6@thread.skype             General                 Standard
19:beb3bb67cdc14e0f8c142245e26e0622@thread.skype             Private Rugby            Private
19:ZbgcM0KcWCYYEtHQfVc9REgP03U8IWowH49DW6KgrFc1@thread.skype Shared Oval Balls         Shared

Get-TeamChannelUser -GroupId $GroupId -DisplayName "Shared Oval Balls" | Format-Table name, Role

Name           Role
----           ----
Kim Akers      Owner
Ken Bowers     Member
Terry Hegarty  Member
Warren Gatland Member
James Hoover   Member

When you’re happy to go ahead and archive the team, you can run the Set-TeamArchivedState cmdlet. The SetSpoSiteReadOnlyForMembers setting controls if the channel’s SharePoint site becomes read-only.

Set-TeamArchivedState -GroupId $GroupId -SetSpoSiteReadOnlyForMembers $True -Archived $True

The User Perspective

Administrators might be quite happy with their ability to archive teams. They have three ways to choose from and all are effective. Things aren’t quite so benign from the user perspective. Channel owners aren’t alerted about team archival, and Teams moves the archived teams into the hidden section of the teams list. The combination means that users don’t find out about archiving until they go to access the team and discover that it’s no longer in their active list.

Users can find the archived team by:

• Looking in the hidden section of the teams list.
• Viewing their teams through the Manage teams option.
• Finding a notification about the team in their Activity Feed.

But when they access the team, they’ll have the happy surprise to discover that it’s read-only (Figure 3), including any shared or private channels they own.

Recovery

The recovery process is straightforward. A team owner or administrator can restore the team and all its channels. Regretfully, the Teams admin center doesn’t seem to include an option to list all archived teams. This is easily done with PowerShell or a Graph query, so it’s a curious oversight. For example:

$ArchivedTeams = Get-Team -Archived $True
$ArchivedTeams | Format-Table GroupId, DisplayName, Description

GroupId                              DisplayName                             Description
-------                              -----------                             -----------
0b9313ca-5b39-43a9-bde3-e0cd4e6ca4e0 Operations Department (Team)            The ops people
06fc846d-141d-4e38-8b29-964903b9013d Windows File Server Replacement Project A team to figure out the detailed plann...
397929bc-198d-4754-9411-c0d4e434908b Web Site Planning                       All about our web site
5cf39594-8a0a-4951-a4e9-20c98d074c40 Xmas Gift Planning                      All about Xmas Gifts
4e9393c3-67e9-4f95-a0df-70103a667c0a Global Trading Desk                     A desk for global traders
889ea6bb-0c1d-4a5e-a1ff-787e290c24f1 BRK3001                                 Composing the best session for Ignite 2016
d2d1b73c-0220-4d1b-ac31-525d9adaa1e6 SSL Admin 2                             SSL Admin test 2
b9aa3cbe-f09c-41a3-a009-d4f9130267b2 Top Performers                          Our top people

To restore (or unarchive, which is the term used in the Teams admin center) all the archived teams, I can do:

$ArchivedTeams | Set-TeamArchivedState -Archived $False

Teams logs audit events when people archive or restore a team. You can read more about the topic here.

As Philip Worrell says, restoring teams from archive might increase the amount of teams sprawl in an organization, but it might also make administrators’ lives a little easier. Wouldn’t that be nice!

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Know Who’s Collaborating in Teams Shared Channels From Outside Your Tenant

Updated 4 March 2024

When Microsoft launched Teams shared channels into public preview (according to MC390413, shared channels will GA in mid-July 2022) the rubber hit the road as tenant administrators tried to figure out the complexities of managing shared channels in production use. It’s true that Microsoft conducted a long private preview with many customers to get shared channels to the point where they squashed obvious bugs and delivered usable software. However, once software is exposed to the kind of examination that an application with 270 million monthly active users can create, other questions bubble to the surface.

Which brings me to the topic of controlling user access to shared channels. The cross-tenant access settings in the External identities section of the Entra admin center control which tenants your organization can access using Entra ID B2B Direct Connect. This is the underlying authentication mechanism for Teams shared channels. It allows users to authenticate in their home tenant and use that authentication, including MFA and device state claims, to access resources in other tenants, if permitted by other tenants.

Entra ID Sign-Ins Track Cross-Tenant Access

Microsoft’s guidance for cross-tenant access settings advises that you can use Entra ID sign in logs to figure out user access to other tenants. It’s true that you can use the PowerShell snippet provided there, but I think we can do better.

The code uses the Get-MgBetaAuditLogSignIn cmdlet from the Microsoft Graph PowerShell SDK to look for sign in records where the resource tenant identifier (the organization delivering a resource like Teams) is not the same as the home tenant identifier (the organization hosting the sign in logs).

$TenantId = (Get-MgOrganization).Id
Get-MgBetaAuditLogSignIn -Filter "ResourceTenantId ne '$TenantId'" -All:$True

The code works (the All switch doesn’t need $True), but the result of the query is a set of sign-in records for both Entra ID B2B Collaboration (guest accounts) and Entra ID B2B Direct Connect. This is a better filter if you want to focus on access to Teams shared channels:

Get-MgBetaAuditLogSignIn -Filter "ResourceTenantId ne '$TenantId' and CrossTenantAccessType eq 'b2bDirectConnect'" -All

Next, although you might recognize the identifier for your tenant, it’s unlikely that you’ll know the identifiers for other tenants (like 22e90715-3da6-4a78-9ec6-b3282389492b). To translate these identifiers into human-friendly tenant names, we need another method.

We’re already connected to the Microsoft Graph, so we can use a Graph query to resolve the identifier into a tenant name.

Finding Tenant Names

Fortunately, a beta query called findTenantInformationByTenantId does the trick. There’s little documentation available, but by running it through the Invoke-MgGraphRequest cmdlet (runs any Graph query when an SDK cmdlet is unavailable), we can retrieve tenant data:

$ExternalTenantId = $Record.ResourceTenantId
$Uri = "https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='$ExternalTenantId')"
$ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get

The tenant information returned is:

Name                           Value
----                           -----
@odata.context                 https://graph.microsoft.com/beta/$metadata#microsoft.graph.tenantInformation
tenantId                       22e90715-3da6-4a78-9ec6-b3282389492b
displayName                    o365maestros
federationBrandName
defaultDomainName              o365maestros.onmicrosoft.com

I assume this web site, which can return the identifier of any Microsoft 365 tenant, uses a similar API.

Flow of the Script

The flow of the PowerShell script to analyze sign-in data is therefore:

• Find sign-in records for Entra ID Direct Connect activity. If you want to process records for Azure B2B Collaboration, change the filter to remove the check against the CrossTenantAccessType property.
• Extract data from each record, including resolving external tenant identifiers to tenant names.
• Report.

In normal circumstances, the sign-in data will feature just a few tenants. It would be slow to run a query to resolve the tenant identifier for every record. To ensure performance, the script resolves a tenant name the first time it is encountered and stores the tenant name identifier and name in a hash table. When the script processes subsequent records for the same tenant, it reads the information from the hash table.

You can download the script from GitHub. Normal warnings apply: use at your peril, etc. and please fix my bugs…

Script Outputs

The output of the script is a PowerShell list containing details of sign-ins which use cross-tenant access to connect to Teams shared channels in external tenants (Figure 1).

The data can be parsed to reveal statistics like which tenants use cross-tenant access:

$Report | Group TenantName | Sort Count -Descending | Format-Table Name, Count

Or to reveal the names of the users who connect to external tenants:

$Report | Group User | Sort Count -Descending | Format-Table Name, Count

Name       Count
----       -----
Sean Landy     4
James Ryan     3
Ken Bowers     3

And so on. I’m sure you’ll find other ways to use the information to track what’s happening with Teams shared channels. The point is that the data is there if you need it. All that’s required is a little massaging of the information.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

How will Organizations Handle Compliance and Backup for Teams Shared Channels?

Teams customers are naturally very excited by the imminent arrival of the shared channel feature in public preview in March. Nice as it will be to be able to implement federated collaboration with your favorite tenants (Figure 1), the introduction of major new functionality in an application comes with its own administrative challenges.

Take the subject of compliance. Microsoft says that all the Microsoft 365 compliance technologies like Data Loss Prevention, retention policies, and communications compliance work with shared channels. Microsoft’s assertion is accurate and it’s all possible because compliance occurs within the tenant which owns a shared channel. In other words, all processing happens within the home tenant and all data created and used within the shared channel remains in that tenant.

Keeping and managing data within the home tenant is analogous to how Teams handles compliance for data generated by guest users in regular and private channels, but I’ve heard some people assume that the federated arrangement between tenants based on Azure AD B2B Connect cross-tenant policies mean that data is shared between tenants. Or perhaps that Teams would create copies of data in both tenants.

Duplication Possible But Not Feasible

From a technical perspective, the Microsoft 365 substrate could duplicate data in the tenants involved in a shared channel. Duplication would be straightforward for Teams messages but would become increasingly messy as other workloads and applications become involved with a shared channel. For instance, the substrate could create a duplicate SharePoint site for each tenant and then synchronize document and lists as users work on them. However, how would sharing work? Or information protection? And do you really want copies of confidential documents to end up in other tenants?

Time and engineering talent could work through and solve the problems. However, I think it is wise of Microsoft to adopt the keep it simple principle from the start and say that a shared channel has one set of data which remains and is managed on the host tenant.

Cloud-Only Mailboxes for Shared Channels

An interesting aspect of the shared channel implementation is the use of a cloud-only mailbox (aka “shard mailbox”) to hold data used by the channel such as calendar items and compliance records. Regular channels store this information in a group mailbox, while private channels don’t have a calendar and store their compliance records in the personal mailboxes of channel members. Microsoft knows that cloud-only mailboxes work well for compliance because this is how they retain data for hybrid and guest users. A big advantage of the implementation is that Microsoft doesn’t have to create special retention processing for shared channels like they had to do for private channels. Normal Teams retention policies already handle the compliance records for hybrid and guest accounts. Now they’ll handle those for shared channels.

Keeping compliance processing to a single tenant certainly simplifies matters, even if compliance managers need to think through how they can manage the activities of their users in other tenants. The obvious answer is to agree a means to co-operate with other tenants when federated conversations need to be investigated. It will be interesting to see how things develop in this area.

Using cloud-only mailboxes for shared channels comes with a downside. Normal administrative and client interfaces have no access to these mailboxes. This might not seem a big thing if compliance processing like eDiscovery searches can find the information in those mailboxes (which they can). The issue lies when applications attempt to use public APIs to access shared channel data for purposes like backups or tenant-to-tenant migrations.

The Teams Backup Challenge

Teams is already the most challenging Microsoft 365 application to backup. The lack of a Microsoft backup API for Teams messages and the degree of integration between Teams and other Microsoft 365 applications like Planner mean that backup ISVs have been forced to use techniques like copying compliance records from Exchange Online. This approach certainly copies compliance records. The problem comes when attempting to restore the data.

Microsoft has a beta Teams messaging API which backup and tenant to tenant vendors use. The restoration of data copied from channel conversations ends up as new messages containing the original topic and all its replies posted into a target channel. Even if this isn’t a perfect representation of the original data, it can be good enough (depending on your need). Chat messages have always been a challenge because the beta API didn’t handle them.

Hope might be on the horizon in the form of the Teams Export APIs. Generally available since October 1, the new APIs seem to offer everything that a backup ISV might need to copy Teams chat and channel messages. Of course, restoring the messages is another day’s work and includes issues like fixing up cross-tenant access policies and the roster of channel membership.

The Export API can handle regular and private channels today. Microsoft hasn’t said if the Export API will be able to handle shared channels. It’s a fair assumption that this capability will be available, but there’s no information about when this might happen. And even when such a capability becomes viable, there’s still the issue of the consumption charging model Microsoft uses for the API. Microsoft has provided some guidelines for how the charging will work when exporting Teams messages using the Export API, but those guidelines need to be worked out into charging patterns for different kinds of tenants, including those with heavy, moderate, and light volumes of Teams messaging.

It’s difficult for backup vendors to have discussions with potential customers when a product has a dependency on an API with such a charging model. I suspect Microsoft will let customers use the Teams Export APIs free of charge for a period to gather data and figure out an acceptable charging regime. When that’s done, tenants will likely pay for the backup transactions they consume using an Azure subscription.

Shared channels are a nice step forward for cross-tenant collaboration. Like all technology, their implementation and management will require new APIs and techniques. The learning continues!

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Laying the Foundation for New Collaboration Scenarios Like Teams Shared Channels

Updated: March 22, 2022

On February 7, Microsoft announced that Azure AD cross-tenant collaboration settings are available in preview. Part of Azure AD B2B Direct Connect, Azure AD cross-tenant access means that users can authenticate in their home tenant and use the credentials gained there to access resources in other tenants, subject to the collaboration settings now in preview. Microsoft says that the new settings allow organizations to control how users collaborate with other Azure AD organizations (Microsoft 365 tenants). Inbound and outbound controls are available to control access on a tenant-wide, group, or application basis, together with the ability to trust security claims from external organizations like multi-factor authentication and device compliance.

External Identities Settings

The new settings are available in the External identities section of the Azure AD admin center. The organizational settings tab is where you define settings for individual Azure AD tenants you want to collaborate with (Figure 1) while the default settings tab is where you define settings to apply to Azure AD tenants in general. Specific settings for another tenant take precedence over the default settings.

Being able to define how individual tenants interact with your tenant allows precise control over who can connect and what they can do. For instance, in Figure 2 we see that the inbound access settings for the O365Maestro tenant allow collaboration via just one application (Office 365). You can add other Microsoft applications to the mix or include other applications if registered in Azure AD.

Note the external users and groups tab. By default, any user can connect with your organization. If you don’t want this to happen, the inbound access settings allow you to define exactly whom from another organization can collaborate with people in your organization. Likewise, the outbound access settings give you control over the people in your organization you want to collaborate outside your tenant. Again, because the whole idea of collaboration is to enable people to work together, the default is to allow everyone to collaborate with external organizations. However, sometimes control is necessary, and you might want to manage who connects with specific tenants, and this is where you can exert that control.

Accepting Security Claims

All Azure AD organizations apply the same fundamentals of authentication to allow users access to resources. It therefore makes sense to accept that a process performed for one tenant is valid for connection to another. If your security posture is higher (for instance, your tenant insists on connections from trusted devices), you can still insist that external connections meet this standard while at the same time accepting valid claims established when users sign into the other organization.

The Trust settings tab defines the set of security claims made by another tenant you are willing to accept. For example, let’s assume that the other tenant enforces MFA for all users. The trust settings for the tenant allows you to accept that the tenant has validated the user’s identity with MFA and won’t issue another challenge from your tenant. Reducing the necessity for multiple MFA challenges removes a major source of user irritation. By default, Azure AD accepts connections from another tenant based on that tenant’s assessment of MFA, compliant (trusted) devices, and hybrid Azure AD joined devices. You can enable or disable each of these claims as shown in Figure 3.

Removing some friction from MFA challenges is a good thing. According to Microsoft, Azure AD customers secure only 22% of Azure AD accounts with MFA. That’s a horrible statistic (albeit showing steady growth over the past few years). The simple fact is that MFA helps accounts resist 99% of brute-force attacks designed to crack passwords, so this is an area where Microsoft 365 tenants need to do better.

Default Settings

If you don’t define settings for an Azure AD organization you want to collaborate with, Azure AD uses the default settings (Figure 4). Like those for individual tenants, the settings break down into B2B collaboration and Trust.

More information about configuring default and specific organization settings for cross-tenant access is available online. Like conditional access policies, it will take time to figure out the best approaches for configuring rules for inbound and outbound access. And like conditional access policies, no one wants to make the mistake of applying a change that blocks collaboration for everyone in a tenant. The advice is therefore to go slowly and understand exactly what effect a proposed change will have on users before proceeding.

Teams Connect the First for Cross-Tenant Access

Microsoft has said that people can connect using “native identities” to collaborate Teams shared channels (aka Teams Connect). It’s therefore no secret that Azure AD cross-tenant access is the foundation to allow users to use credentials obtained within their home tenant to connect with people in a shared channel in an external organization.

Teams shared channels (aka Teams Connect) are now in public preview. Many criticized Microsoft’s slowness in delivering shared channels but given that the feature depends on a new way of authentication and Azure AD collaboration that is only just available in preview, it’s understandable why the delay happened. After all, you don’t want authentication from another tenant to potentially compromise sensitive information stored in a shared channel. Teams Connect is likely the first app to exploit cross-tenant access. I don’t think it will be the last.

Azure AD cross-tenant access won’t mean that guest accounts will go away anytime soon. Many valid scenarios exist to demonstrate the usefulness of guest accounts. Cross-tenant access gives organizations a new way of collaborating to add to the methods enabled by guest accounts. It’s all goodness.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

On

July 12, Microsoft released version 16.0.21411.1200 of the SharePoint Online PowerShell module, installable from the PowerShell Gallery. The updated module is especially notable because the Get-SPOSite cmdlet boasts three new properties to inform administrators if sites are connected to Teams. The properties are:

• IsTeamsConnected: Set to True if the site is connected to a team.
• IsTeamsChannelConnected: Set to True if the site is connected to a Teams private or shared channel. These sites have IsTeamsConnected set to False.
• TeamsChannelType: Set to None for teams-connected sites and to Private for sites belonging to private channels or Shared for sites belonging to shared channels (due later this year).

New View of Teams Sites

The updated module aligns with the effort to make SharePoint Online more manageable for teams-connected sites through a UI refresh and by showing details of channel-connected sites in the SharePoint Online admin center with a new Sites connected to Teams view (Figure 1). This view is in preview at present and should become generally available later this year.

The new view lists all teams-connected sites and indicates how many of the channels in a team have a channel-connected site. Clicking the link for the channel sites exposes further information (Figure 2).

The net effect of the change is that SharePoint administrators will see information about teams-connected and channel-connected sites in the SharePoint Online admin center which isn’t available today. Access to information about channel-connected sites is read-only. This is because these sites inherit settings from the parent team site. It also ensures that management of the channel-connected sites remains with the channel owners.

Using the New Teams Site Properties in PowerShell

Coming back to PowerShell, the new properties make it easier to find and report details of Teams-connected sites. You can still do this using the Get-UnifiedGroup cmdlet, which offers the advantage of exposing group information more easily. Now you have the option to check if team-connected sites have private or shared channels.

Here’s some quick and dirty PowerShell to report channel-connected sites. The code:

• Creates an array of sites connected to Teams.
• Creates another array of channel-connected sites.
• Loops through the sites array to see if any matching channel-connected sites are present and reports these sites. Remember, a team can have up to 30 private channels.

# Find Teams-connected site
[array]$Sites = Get-SPOSite -Limit All | ? {$_.IsTeamsConnected -eq $True}
# Find channel connected sites
[array]$ChannelSites = Get-SPOSite -Limit All | ?{$_.IsTeamsChannelConnected -eq $True}

$SiteCount = 0
$ChannelData = [System.Collections.Generic.List[Object]]::new()
ForEach ($Site in $Sites) {
   [array]$MatchedSites = $ChannelSites | ? {$_.Url -Match $Site.Url}
   If ($MatchedSites) {
      $SiteCount++
      ForEach ($MSite in $MatchedSites) {
       $ReportLine = [PSCustomObject][Ordered]@{  
         Parent      = $Site.URL
         Title       = $Site.Title
         URL         = $MSite.URL
         ChannelType = $MSite.TeamsChannelType }
       $ChannelData.Add($ReportLine)
      } # End ForEach
   } # End if
} # End Foreach
Write-Host ("Total of {0} channel-connected sites found for {1} sites" -f $ChannelData.Count, $SiteCount)

Here’s an example of a record for a channel-connected site:

Parent      : https://office365itpros.sharepoint.com/sites/CorporateAcquisitionPlanning2020
Title       : Corporate Acquisition Planning 2020
URL         : https://office365itpros.sharepoint.com/sites/CorporateAcquisitionPlanning2020-LegalDiscussions
ChannelType : PrivateChannel

Figuring Out Inconsistencies

Interestingly, I found instances where the Microsoft 365 group which originally owned a team-connected site was no longer available in the tenant, but team-connected and channel-connected sites still existed. This is likely due to retention policies where sites come within the scope of a retention policy and the group did not. I used the following code to find these channel-connected sites:

# See if we can find parent groups
ForEach ($CSite in $ChannelSites) {
   $MatchURL = $CSite.URL.Split("-")[0]
   $Match = $Sites | ? {$_.Url -Match $MatchURL}
   If (!($Match)) {Write-Host "Can't find parent team-connected site for channel-connected"  $CSite.URL }
}

I also found some inconsistencies between the number of channel-connected sites reported using the new properties and the older method of using the site template to identity these sites:

$TTSites = Get-SPOSite -Limit All -Template "TEAMCHANNEL#0"

Some testing revealed that this is due to some provisioning delays in updating site properties. Essentially, if you update the membership of a channel, you force synchronization to update site properties.

Exposing Channel-Connected Sites

There’s no doubt that these updates add value. When Microsoft introduced private channels in November 2019, many complained that the sites used for sharing documents in private channels were invisible (they weren’t, but you had to use PowerShell to see them). Exposing details of private channels (and soon, shared channels) in the SharePoint Online admin center is a good thing: adding the properties to allow better filtering and reporting of channel-connected sites in PowerShell is even better.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.