Fabrikam: container labels, defaults, and 300 unlabeled sites
Fabrikam Manufacturing runs 900 Teams and 40 SharePoint sites on Microsoft 365 E5. Sensitivity labels are scoped for files and emails and for groups and sites. The label 'Confidential' carries site and group settings that set privacy to Private and restrict external sharing to people inside the organization. Fabrikam wants every new team created Private with that label and no user override. Testers report two problems: teams created from the Teams client show an empty label picker, and a site created in the SharePoint admin center keeps an external sharing setting of Anyone. Separately, 300 existing sites carry no container label, and the compliance lead wants every file in the Engineering Specs library labeled Confidential at upload, including the 12,000 files already there.
1. Why is the label missing in the Teams creation experience, and what settings make the Confidential label apply automatically with no override?
Read the worked answer
Why the picker is empty
- The label policy must be published with the Groups and sites scope and include the creating users; a files-and-email-only publication never surfaces in Teams.
- The label must have site and group settings configured. A label published for sites without settings will tag a site but enforce nothing.
- Check replication: policy changes can take hours and occasionally longer to reach Teams, so retest after propagation before debugging further. Also confirm the label order is what you expect, since conflicting container labels resolve by priority.
Making it automatic and non-overridable
- Set the default label for sites and groups in the label policy to Confidential. That is the only mechanism that pre-selects a container label at creation.
- You cannot hard-lock the picker through policy; shrink the choice set instead. Publish container-capable labels narrowly so team creators see Confidential only, and keep the wider taxonomy for files.
- The Private and external-sharing values on the label then win over whatever the creator picks in the wizard, which is why the SharePoint admin-created site still showed Anyone - it was created outside the label's reach and must be labeled explicitly.
Verify
- Create three teams from Teams, three from the SharePoint admin center, and one group from Entra, then confirm privacy and sharing via the site properties and a PowerShell site inventory.
2. Plan the labeling of the 300 existing sites. What breaks first if you script it in one pass, and how do you sequence it?
Read the worked answer
What breaks first: external collaboration.
- Applying a container label rewrites the site's sharing settings. Sites whose current setting is Anyone or New and existing guests will flip to internal-only the moment the label lands, and external partners lose access without warning. That is the real risk, not the scripting.
Sequence
- Inventory: export every site with its current sharing setting, owner, and external user count from the SharePoint admin center. Segment the 300 into internal-only, guest-sharing, and anyone-link sites.
- Pick a second label for genuinely external-facing sites (for example Confidential - Partner) with a less restrictive sharing setting, so labelling does not silently become a de-sharing project.
- Pilot ten sites including at least three guest-sharing ones. Notify owners, apply labels via Set-SPOSite with the label GUID, and confirm the sharing value in the properties blade afterwards.
- Batch the remainder by segment, owner-notified, over several weeks; keep a rollback list of original settings.
- Guard the future: default label on the policy, restricted label choice for creators, and a scheduled report that flags any site created or edited without a container label.
Check before you promise a date
- Setting changes can lag indexing, so validate behaviour by re-reading site properties rather than trusting the immediate UI.
3. The compliance lead wants all files in the Engineering Specs library labeled Confidential at upload, including the 12,000 already there. Which controls do you use, and what are the gaps?
Read the worked answer
Two different problems, two mechanisms
- Future uploads: set the default sensitivity label for that document library in library settings. It requires the label to be published to the users, applies on create and upload, and inherits a default into Office when a new file is made from the library.
- Existing 12,000 files: a library default does nothing retroactively. Use a service-side auto-labeling policy scoped to that site (or a scan-and-set script), running in simulation first to see the match rate before enforcing.
Gaps to state plainly
- The library default is a nudge, not a lock: users can change the label, and a higher-priority auto-labeling policy can override the choice later. If the label must stick, use downgrade justification plus a DLP rule that alerts on label removal.
- Auto-labeling at rest is asynchronous; expect days, not minutes, and items changed mid-scan may be picked up on the next pass. Do not report coverage as complete until Content explorer shows it.
- Encryption on this label would make the auto-label pass harder to validate and would break co-authoring if it uses fixed permissions; if the CISO wants encryption here, settle the permissions model first.
Success measure: sampled spot checks plus a Content explorer count of files in that site path with the Confidential label, compared before and after each wave.