Microsoft 365 Groups and Teams Governance

Microsoft 365 Groups (formerly Office 365 Groups) are the foundational membership object in Microsoft 365. They are not just a distribution list or a security group; they are a full-fledged identity object in Azure Active Directory (Azure AD) that provisions and manages access to a set of shared resources. Every Microsoft 365 Group has a unique object ID in Azure AD and can be assigned an email address (SMTP), a SharePoint site, a shared mailbox, a calendar, a OneNote notebook, and a Microsoft Teams team (if Teams-enabled). The group itself is the security principal; when you add a member to the group, that member automatically gains access to all connected resources.

Each Microsoft Teams team is backed by a Microsoft 365 Group. When you create a new team, a Microsoft 365 Group is automatically created (unless you use an existing group). The team's membership is synchronized with the group's membership. The team's channels are stored in the group's SharePoint site (by default, a private channel creates a separate site collection). The group's Exchange calendar appears as the team's calendar. The group's shared mailbox is used for team email. This tight integration means that governance decisions made at the Group level directly affect Teams.

To prevent accumulation of stale groups, Microsoft 365 Groups can have an expiration policy. You can set a default expiration period (e.g., 180, 365, or 730 days) for all groups in the tenant. The policy is configured in the Azure AD admin center under "Groups" > "Expiration". When a group reaches its expiration date, it is first flagged for renewal. Group owners receive an email notification 30 days, 15 days, and 1 day before expiration. If the group is not renewed (either by an owner or an administrator), it is deleted. The deletion is soft; the group is moved to the Azure AD recycle bin and can be restored within 30 days. After 30 days, it is permanently deleted. - Default expiration period: 365 days - Renewal notification schedule: 30, 15, and 1 day before expiration - Retention after deletion: 30 days in recycle bin - Only groups with owners can be renewed; if a group has no owners, it is automatically deleted unless an admin intervenes

Naming policies enforce consistency and prevent inappropriate group names. They consist of two parts: a prefix/suffix and blocked words.

Naming policies are configured in the Azure AD admin center under "Groups" > "Naming policy". They apply to all Microsoft 365 Groups, including those created via Teams, Outlook, SharePoint, and other clients.

By default, guest users can be added to Microsoft 365 Groups. However, you can control guest access at the tenant level and per group. The tenant-level settings are in the Azure AD admin center under "External Identities" > "External collaboration settings". You can restrict guest invitations to specific admin roles or allow all users to invite guests. For groups, you can configure whether guests can be added via the "Microsoft 365 Groups" settings. Additionally, you can use dynamic membership rules to automatically add or remove guests based on attributes.

Azure AD provides several policy types to govern groups:

Administrators can manage groups using PowerShell (AzureAD module or Microsoft Graph PowerShell SDK) and the Microsoft Graph API. Common tasks:

New-AzureADGroup -DisplayName "Project X" -MailEnabled $true -MailNickname "ProjectX" -SecurityEnabled $false -GroupType "Unified"

Set-AzureADDirectorySetting -Id $settingId -Values @{"GroupLifetimeInDays"=365}

Add-AzureADGroupMember -ObjectId $groupId -RefObjectId $guestObjectId

Every Microsoft 365 Group has a connected SharePoint team site. The site is created with a default document library and can be customized. When a group is deleted, the SharePoint site is also deleted (moved to recycle bin). The site's permissions are synced with the group; changes to group membership automatically update SharePoint permissions. The same applies to the group's OneNote notebook and Planner plan (if enabled).

Teams governance builds on Groups governance but adds additional layers:

The MS-102 exam tests your ability to configure and manage Microsoft 365 Groups and Teams governance. You need to know:

Problem: The company had thousands of Teams and Groups created without governance, leading to duplicate groups, inappropriate names, and security risks from stale groups.

Solution: The IT team implemented a naming policy with a standard prefix (e.g., 'CONTOSO_') and blocked words (e.g., 'confidential', 'HR-only'). They set an expiration policy of 365 days and configured access reviews every quarter for critical groups. They also restricted guest invitations to IT admins only.

Configuration: Using PowerShell, they created a directory setting for the naming policy:

$setting = New-AzureADDirectorySetting -TemplateId "62375ab9-6b52-47ed-826b-58e47e0e304b"
$setting["PrefixSuffixNamingRequirement"] = "GRP_[GroupName]_2024"
New-AzureADDirectorySetting -DirectorySetting $setting

Outcome: Group creation became consistent, stale groups were automatically deleted, and guest access was controlled. The IT team reduced security risks and improved compliance.

Problem: The organization needed to ensure that only authorized personnel could access patient data shared via Teams. They also needed to audit membership changes.

Solution: They enabled guest access only for business partners and required MFA for all external users via Conditional Access. They created an access review policy for groups containing sensitive data, with weekly reviews. They also used Azure AD audit logs to track membership changes.

Configuration: They created a Conditional Access policy targeting all guest users:

$policy = New-AzureADMSConditionalAccessPolicy -DisplayName "Require MFA for guests" -State "Enabled"
$conditions = New-AzureADMSConditionalAccessCondition -Users @{IncludeUsers=["GuestsOrExternalUsers"]}
$controls = New-AzureADMSConditionalAccessGrant -Controls @{RequireMfa=$true}
Set-AzureADMSConditionalAccessPolicy -PolicyId $policy.Id -Conditions $conditions -GrantControls $controls

Outcome: Guest access was secured, and compliance requirements were met. The access reviews ensured that only current partners had access.