The End of Parent-Child Label Relationships

Message center notification MC1111778 (last updated 24 September 2025, Microsoft 365 roadmap item 386900) announces the modernization of sensitivity label grouping to a “dynamic architecture” consisting of labels and label grouping rather than parent and child labels. The new architecture supports moving sensitivity labels between groups “without losing referential integrity.” In other words, the settings of sensitivity labels remain intact when they are moved from one label group to another.

Removing the Last Vestiges of AIP

When Microsoft launched Azure Information Protection (AIP) labels in 2016, they adopted a two-tier parent-child model for organizing the display of labels. In this model, the parent label functions as a navigation location for child labels and cannot be applied to files. When sensitivity labels took over from AIP labels, the same arrangement was kept. In Figure 1, the Secret label is the parent and the All Company and My Team are child labels.

When details of an assigned label are viewed in client user interfaces, the structure is displayed as Parent\Child (Figure 2).

The problem with the parent-child structure is its strict nature. Once a child label is created and deployed in active use, it becomes very difficult (if not practically impossible) to change the labeling structure to reflect current business requirements. The inflexible nature of the parent-child structure is the main reason why I never recommended its use to customers. It’s difficult enough to construct a workable labeling structure for a tenant without having to deal with inflexible groupings.

Public Preview and Migration

Microsoft is currently deploying the modern label architecture in public preview with the aim of attaining general availability in December 2025. New tenants created after 1 October 2025 must use the new architecture. No administrator action is required before general availability occurs, but it might be a good idea afterwards to review the current label structure to see if sensitivity labels can be presented in more effective manner to end users.

When a tenant is upgraded, any existing parent-child groups are migrated to the new architecture. During the preview, if a tenant has parent-child label groups, they can use the manual migration method invoked from the Information Protection section of the Purview portal (Figure 3). Migration is an irreversible process, so take the time to read up before plunging ahead and migrate a set of sensitivity labels in a test tenant first.

Launching the migration is preceded by notification of what the expected outcome will be (Figure 4). My tenant has used sensitivity labels since their AIP predecessors and has accumulated many different sensitivity labels used for content protection and container management over the years, including two parent-child groups (for testing only).

The migration took just a few seconds and only difference seen afterwards is that the parent labels are now label groups and the child labels are members of those groups. The Secret parent viewed earlier became a label group and also a standalone sensitivity label. The standalone label takes the name, GUID, and settings as the original parent label. Following the migration, I updated the display name of the affected labels and label groups to make their function obvious.

The new architecture exposes options in the Purview portal to move sensitivity labels into and out of groups. This is the big advantage of the change as administrators can now easily construct and change label groups according to business demands. For instance, I created a label group called Email Labels to organize the sensitivity labels most appopriately used for email to give additional guidance to end users. Figure 5 shows how the new label group appears in OWA.

Notice how all the sensitivity labels in the Email Labels group have the same label color. This might affect the carefully-crafted custom colors you might have assigned to sensitivity labels in the past. Another important change is that the standalone labels moved into the label group have priority orders based on the priority assigned to the label group. Label priority is supposed to indicate the degree of confidentiality or sensitivity of files that labels are applied to, so some rearrangement of labels is probably needed here. A change in label priority can lead to an increase in document mismatch notifications, and that’s not a good thing.

Although you can move container management labels into label groups there’s no point in doing so. First, organizations tend to have relatively few container management labels, so there’s no need for grouping. Second, the applications that use container management labels, like Teams and SharePoint Online, display container management labels in a simple list.

PowerShell Changes

A set of cmdlets in the security and compliance module support sensitivity labels. The label settings manipulated by the cmdlets use the same properties to update label group membership as was used to associate a child label with a parent label. For instance, a label group has the isParent and isLabelGroup settings set to true:

$Label = Get-Label -Identity 'Email Labels'

$Label.Settings
[isparent, True]
[islabelgroup, True]

A sensitivity label in a label group has the isParent property set to false and the identifier for the label group in its ParentId property:

$Label = Get-Label -Identity '1b070e6f-4b3c-4534-95c4-08335a5ca610'

$Label.Settings
[contenttype, File, Email]
[isparent, False]
[parentid, 62acd157-1757-4361-9a53-71ea316279ca]

To move a label into a label group, run the Set-Label cmdlet and update the ParentId parameter with the identifier for the label group. Here’s an example of moving a label into the Email Labels group:

Set-Label -Identity 'Employee Confidential' -ParentId (Get-Label -Identity 'Email Labels').ImmutableId

To move a sensitivity label out of a label group, pass $null or the identifier for another label group as the parent identifier.

Heading to a New Architecture

Referring to a new way to manage sensitivity labels for display in applications as a new architecture is a stretch. However, it’s still a good change. It will take time for tenants to figure out how to best use label groups, but that will come in time. In the meantime, the task is to migrate to the new architecture, either manually or by waiting just a few more weeks.

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.

Advanced Setting Manipulated by PowerShell

For the last year, Microsoft has steadily added to the ability of sensitivity labels to manage different aspects of SharePoint Online sites. Possibly because of a desire not to clutter up sensitivity label settings in the GUI, the developers chose to manage the settings via PowerShell. Adding to the ability to manage the external sharing capability and default link settings, administrators can now control site sharing permissions (a preview feature) via a new advanced sensitivity label setting.

In the SharePoint Online browser interface, this option is available through Site Permissions – Site Sharing (Figure 1).

It’s possible to set site sharing permissions to block all but site owners with PowerShell by running the Set-SPOSite cmdlet with the DisableSharingForNonOwners switch. For example

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/Office365Adoption -DisableSharingForNonOwners

However, the Set-SPOSite cmdlet doesn’t allow administrators to enable site sharing for non-owners. It’s a very simple off switch that cannot go back or set site sharing permissions to the option where only site owners can share the site. The new capability for sensitivity labels delivers a way to address these shortcomings, but only for sites assigned sensitivity labels with the advanced setting defined.

Available Site Sharing Permissions

Three site sharing permissions settings are available (the descriptions are from the GUI shown in Figure 1):

• MemberShareAll: Site owners and members can share files, folders, and the site. People with edit permissions can share files and folders. This is usually the default setting assigned to new sites.
• MemberShareFileAndFolder: Site owners and members, and people with edit permissions, can share files and folders, but only the site owners can share the site.
• MemberShareNone: Only site owners can share files, folders, and the site.

Updating the Site Sharing Permission

To assign a new site sharing permission, connect to the compliance endpoint by first connecting to Exchange Online (Connect-ExchangeOnline cmdlet) and then running the Connect-IPPSSession cmdlet. You then have access to the compliance cmdlets and can run the Set-Label cmdlet to update the MembersCanShare advanced setting. For example:

Set-Label -Identity 'General Access' -AdvancedSettings @{MembersCanShare= 'MemberShareFileAndFolder'}

To ensure that the update worked, run the Get-Label cmdlet:

Get-Label -Identity "General Access" | Select-Object -ExpandProperty Settings

[contenttype, Site, UnifiedGroup]
[tooltip, General access to information in a team, group, or site that's available to anyone in the organization plus guest members.]
[displayname, General Access]
[memberscanshare, MemberShareFileAndFolder]

Note that the Get-Label cmdlet only lists advanced settings that apply to a sensitivity label. For instance, the external sharing capability setting doesn’t appear here because it is not set for the General Access label.

Wait and Verify

The new label setting must propagate to SharePoint Online before it applies to the sites assigned the sensitivity label. The synchronization process usually takes about 24 hours, but it can take longer. After waiting for a day or so, to verify that the change worked, select a site with the sensitivity label you updated and check its site sharing permissions. Because we selected ‘MemberShareFileAndFolder’ as the value for the setting, you should see permissions as shown in Figure 2.

If the permission doesn’t show up as expected, check that the label settings are correct and wait another day before checking again. If nothing budges after a week, it’s time to seek assistance from Microsoft Support.

GUI Updates Take Time

Some will ask why Microsoft doesn’t expose advanced sensitivity label settings in the (now renamed) Microsoft Purview compliance portal. After all, many settings are managed through sensitivity labels in the GUI, including external sharing capability (Figure 3). This setting was originally only settable through PowerShell.

Although I don’t know for sure, I suspect that the answer is “development time.” In other words, after a new sensitivity label setting becomes generally available, extra development effort is necessary to update the GUI and make sure that everything works as it should. Patience is a virtue…

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Build Organization-Wide Consistency in Sharing Behavior

Updated: February 24, 2022

Sensitivity label container management settings can control the sharing capability of SharePoint Online sites. Separately, the advanced settings of sensitivity labels can control the default sharing link settings for sites and documents. Enforcing consistent sharing capabilities is a good example of how container management through sensitivity labels make it easier to apply organizational standards across sites in a Microsoft 365 tenant.

Controlling Site Sharing

If you create a sensitivity label and configure it to apply a sharing capability of “Only people in your organization,” any site which receives the label automatically enforces that sharing capability. Site owners cannot change the sharing capability of a site without changing the label assigned to the site. Although tenant administrators can’t stop site owners changing a label, this is an auditable action which organizations can track to revert if necessary.

Controlling Default Sharing Link Settings

SharePoint Online creates sharing links when users share content from a site (Figure 1). The sharing link identifies what the person receiving the link can do with the content (read or edit). It also identifies who can use the link (anyone, specific people, tenant accounts).

SharePoint administrators can configure settings for the default sharing link for a site through PowerShell by running the Set-SPOSite cmdlet from the SharePoint Online management module. The relevant parameters are:

• DefaultSharingLinkType: Defines the default sharing link type for the site. For example, if this is “Internal,” the default sharing link type is set to anyone in the organization. The default is None, meaning respect the organization setting (defined with Set-SPOTenant).
• DefaultLinkPermission: Set to View or Edit to define what the link recipient can do. The default is None, meaning respect the organization setting.
• DefaultLinkToExistingAccess: The default is False. If set to True, the default sharing link type is set to People with existing access.

Defining a default sharing link type does not mean that site users are limited to the settings used to create sharing link. Users can update their sharing links to use other settings (for example, change the permission from edit to view), providing they remain within the constraints defined for the site’s external sharing capability.

Updating Sensitivity Labels with Default Sharing Link Settings

Now generally available (February 2022), you can configure the advanced settings of sensitivity labels to control the default sharing links generated for sites. The advantage of this method over configuring settings using Set-SPOSite is that any site assigned a label inherits the settings automatically. You don’t have to configure each site individually.

For now, configuration is by updating the advanced settings for a label with PowerShell. Given past practice, it’s possible that we will see a GUI for advanced label settings sometime in the future.

To update label settings, you connect to the compliance endpoint with PowerShell. Do this by running the Connect-IPPSession cmdlet from the Exchange Online management module. You can then use the Set-Label cmdlet to update the sensitivity labels. The setting names for Set-Label do not correspond exactly with the values used by Set-SPOSite. Here are the values:

• DefaultSharingScope (DefaultSharingLinkType) can be SpecificPeople, Organization, or Anyone.
• DefaultShareLinkPermission (DefaultLinkPermission) can be Edit or View.
• DefaultLinkToExistingAccess is True or False (default False).

You can update link settings separately or together. For example, these commands set the default sharing scope and permission in two steps:

Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultSharingScope = "SpecificPeople"}
Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"}

Or set the two values in one command:

Set-Label -Identity 'Non-Business Use' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"; DefaultSharingScope = "Anyone"}

To check the settings for the label and confirm the configuration, run the Get-Label cmdlet:

Get-Label "Non-Business Use" | Select -ExpandProperty Settings
[contenttype, Site, UnifiedGroup]
[tooltip, Apply this label to a team, group, or site intended to support a non-business use such as a sports club or approved employee society.]
[displayname, Non-business use]
[defaultsharingscope, Anyone]
[defaultsharelinkpermission, Edit]

To set the default sharing link for the site so that it overrides any existing setting and uses people with existing access instead, run:

Set-Label -Identity 'Confidential Access' -AdvancedSettings @{DefaultLinkToExistingAccess  = "True"}

Like any other changes made to sensitivity labels, it can take up to 24 hours before SharePoint Online respects updates to the default sharing link settings.

Update Default Sharing Link Settings for Documents

Being able to control the default sharing link settings for sites by applying sensitivity labels is good. Being able to control default sharing link settings at a document level is even better. Microsoft added this capability between the preview and general availability. The same mechanism is used.

• Update a sensitivity label with default sharing link settings.
• Apply the sensitivity label to documents.
• If users share the labeled documents, SharePoint Online or OneDrive for Business use the settings from the label to generate the sharing link unless the site settings are more restrictive, in which case they take precedence.

The idea here is that you might have some specific documents in a site that you want people to pay attention to if they share the documents. The hope is that users will notice the differences in the sharing link generated by SharePoint Online or OneDrive for Business and recognize that they should be extra careful. The good thing is that people often accept default sharing link settings without question. The bad thing is that people mightn’t notice that a document is more confidential than the rest…

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 development as they happen.

Two Notifications Mark a Special Update

A feature so good that it requires two identical message center notifications must be worthwhile. Such is the case for the ability of sensitivity labels container management to control the external sharing capability of SharePoint Online team sites, as announced in MC244217 and MC244216 on March 12. Both point to Roadmap item 70735.

Information Protection and Container Management

Sensitivity labels can include settings for information protection and container management. Information protection usually means that the assignment of a label to an Office document, Azure Purview data (preview), Power BI objects, or other files will encrypt the target content using Microsoft Information Protection (rights management). Container management means that labels impose settings on a Microsoft 365 group, including the team or SharePoint team site belonging to the group. A single label can include both information protection and container management settings and is therefore applicable to both files and containers, or the scope of the label can be one or the other use. I favor a restricted label scope because I think it makes labels easier to manage.

Container Management Settings

When Microsoft first introduced the ability of sensitivity labels to control container settings, a limited number of controls were available. You can configure a label to:

• Control access to the container to Azure B2B Collaboration guest accounts. Previously, this control over containers could only be set by updating the properties of the group with PowerShell. The options are to allow or block guest access.
• Set the access to be public or private. If a label is not present, the group owner can decide whether the group is public (available to any tenant user) or private (restricted to the group membership).
• Limit access to documents in a SharePoint when using unmanaged devices.

The set of available controls is useful and sensitivity labels are much better than the alternative (like text-based classifications), but Microsoft’s intention always was to expand the number of controls to make sensitivity labels a much more powerful policy-driven management method for containers. Adding control over the sharing capability for SharePoint sites is further evidence of their intent.

Controlling External Access to SharePoint Online Sites

Organizations often store confidential or sensitive documents in SharePoint sites. SharePoint Online supports four values for site sharing capability to control the degree of external sharing permitted for documents in a site:

• Disabled – allow no external sharing outside the organization.
• ExistingExternalUserSharingOnly – allow sharing only with the guest users already in your organization’s directory.
• ExternalUserSharingOnly – allow users to share documents with new external users, who must accept the sharing invitations and go through an authentication process to create a guest account.
• ExternalUserAndGuestSharing – allow sharing with all external users, and by using anonymous access links (Anyone links).

SharePoint Online administrators and site owners can set the sharing capability through:

• The SharePoint Online admin center.
• PowerShell, using the Set-SPOSite cmdlet to update the SharingCapability setting.
• And now, by assigning a sensitivity label which has the external sharing control configured.

Remember that SharePoint Online won’t allow you to assign a less restrictive access to a site than allowed by the tenant sharing setting. In other words, if the tenant explicitly blocks anyone access for all sites, assigning anyone access through a label will have no effect.

Setting External Sharing Capability in a Sensitivity Label

When editing a sensitivity label, administrators can define what sharing capability is set when an owner or administrator assigns the label to a site (Figure 1).

The Site Owner View

Not every site owner knows about admin tools, and a major benefit of controlling sharing capability with sensitivity labels is that it makes it easier for site owners to assign the appropriate level of sharing based on their knowledge of the content within the site. At least, that’s the theory, and a lot depends on the clarity of the names chosen for sensitivity labels. Ideally, the names should convey how sensitive the information stored in the site is (Figure 2).

Applying a sensitivity label to a group or team also applies it to the site and selecting a new sensitivity label for a site also applies it to the associated group and team.

PowerShell Support for Container Management

The PowerShell cmdlets to interact with sensitivity labels are available after connecting a session to the compliance endpoint. The easiest way to do this is to run the Connect-IPPSSession cmdlet from the Exchange Online management module.

Once connected, we can use the Get-Label cmdlet to find details of sensitivity labels and the Set-Label cmdlet to update their settings. For example, not all sensitivity labels are configured for container management, so to find the set of labels scoped for container management, run this code:

Connect-IPPSSession
$Labels = Get-Label
ForEach ($Label in $Labels) {
   If ($Label.ContentType -match "Site, UnifiedGroup") {
   Write-Host "Label" $Label.DisplayName "has container actions" }
}

Label Non-business use has container actions
Label General Access has container actions
Label Guest Access has container actions
Label Limited Access has container actions
Label Confidential Access has container actions

As an example of how to use Set-Label, here are two examples of updating labels to set different sharing capabilities.

Set-Label -Identity Confidential -AdvancedSettings @{sharingcapability="ExistingExternalUserSharingOnly"}
Set-Label -Identity Secret -AdvancedSettings @{sharingcapability="Disabled"}

After applying a label with a sharing capability setting configured to a site, SharePoint updates its sharing capability. You can check that the settings have changed with the Get-SPOSite cmdlet:

Get-SPOSite -Identity "https://office365itpros.sharepoint.com/sites/BlogsAndProjects/" | Select SharingCapability, SensitivityLabel

SharingCapability SensitivityLabel
----------------- ----------------
         Disabled 27451a5b-5823-4853-bcd4-2204d03ab477

Checking that Everything Works

Of course, it’s a good idea to check that the sharing capability set in a sensitivity label works after assigning the label to a site. Let’s assume that you assign a label which disables external sharing. The easy test is to see if sharing works. As Figure 3 shows, it is not allowed and you see one of SharePoint’s famous OSE errors.

Being able to control external sharing for SharePoint sites is just the latest control for sensitivity labels. Microsoft plans more in the future. With this in mind, if you haven’t already started using sensitivity labels, perhaps now is a good time to make a start?