通过自动化保持团队整洁

群体扩张的问题

Microsoft 365 组已经存在很长时间了，虽然毫无疑问有一些很好的用途，例如共享邮箱的替代品以及可怕的公共文件夹的潜在替代品，但它们确实通过 Microsoft Teams 取得了长足进步。每个团队都由 Microsoft 365 组支持，每个组都包含来自平台不同区域的各种组件，构成具有多个用例的单个对象（某种程度上）。

组蔓延的问题并不是 Teams 所独有的，但默认情况下为最终用户快速采用和轻松创建 Teams 肯定无法帮助忙碌的租户管理员保持环境整洁。向最终用户提供有关如何负责任地管理 Teams 的教育可能会有所帮助，但与 Microsoft 365 中的大多数内容一样，它可能是一个不断变化的目标。

管理员可以使用各种控件，这使得管理组/团队变得更加容易，但本机没有统一的端到端解决方案。话虽这么说，通过一些独创性和一些自动化，可以通过一些方法来控制团队创建，而无需太多开销。

注意：本文中概述的代码示例均可在 GitHub 上找到，以帮助您开始使用自己的解决方案。

重点控制领域

Teams 的一些关键区域有助于在更精细的级别上进行控制，以保持租户中的一切井然有序。规划 Teams 自动化脚本时，请务必考虑以下方面，因为它们确实可以帮助定义不同类型 Teams 的规则。

组命名：Microsoft Entra 管理中心中的组命名策略允许 Microsoft 365 组（和团队）使用一些基本的命名约定功能，但实际上，它们严重缺乏灵活性。基于静态用户属性的组名称理论上是一个好主意，但错过了几个关键用例，例如跨部门团队或区分内部和外部可用的团队。在大型组织中有用的命名的另一个方面是控制所使用的 SharePoint 站点 URL。默认情况下，Microsoft 365 使用组邮件昵称来设计关联站点的 URL。根据租户内的 SharePoint 结构，这可能不够精细。

组过期：组过期是从租户中删除旧组的有效方法。 Azure AD 组生命周期策略是配置此策略的一种简单方法，但只有一个可用策略，除非您在其中包含所有组，否则需要针对要包含或排除的每个组进行更新。

访问和共享控制：组织内有不同类型的组或团队，应考虑不同级别的访问和共享。例如，面向客户的项目团队应具有与 HR 部门团队截然不同的外部访问配置。使用敏感度标签可以轻松配置不同组类型的配置，如有关在 SharePoint 网站、Microsoft Teams 和 M365 组中使用敏感度标签的三部分系列中所述。不幸的是，以编程方式分配敏感度标签需要使用 Graph API 的委托权限，这在非交互式运行时很难实现。出于本示例的目的，我直接配置组和站点设置，而不是使用标签。

所有权：孤立组（不再拥有所有者的组）是 Microsoft 365 中的一个事实。有一些通过策略或脚本进行管理的方法，组所有权治理策略文章中对此进行了讨论。默认情况下，组在创建时需要至少一名所有者，但最好至少有两名所有者。

权利管理：对于敏感群体，初始设置只是成功的一半。确保不断审查和确认授予特定组或站点的访问权限非常重要。这是许多管理员面临的一个更广泛的问题，并非 Microsoft 365 所独有。管理资源访问的生命周期是确保环境安全的关键。对此进行控制的一个好方法是通过权利管理，如本系列：权利管理指南中所述。

从哪里开始？

我提到的领域只是 Microsoft 365 中可用的几个不同解决方案和设置，它们本身代表解决方案的一部分。将每个部分组合在一起并实现自动化是我们真正增加价值（并节省时间）的地方。

直接开始构建解决方案，Azure 自动化非常适合自动化此类操作，因为它运行可靠且安全。网上还有大量很好的示例，展示了如何将 Azure 自动化与 Microsoft 365 和 Microsoft Graph SDK 结合使用。

不过，使用 Graph API 时存在一些限制，特别是在配置 SharePoint Online 时。 Microsoft 最近在 Graph beta 端点中添加了对 SharePoint Online 租户设置的（非常）有限的 Microsoft Graph 支持，但这还不允许配置每个站点所需的粒度。为了解决这个问题，PNP PowerShell 模块填补了空白。

准备环境

有许多教程可用于在 Azure AD 中创建注册应用程序并生成所需的身份验证和同意参数，，因此我不会在这里过多介绍该配置。简而言之，我们使用系统分配的托管标识来配置一个新的自动化帐户，类似于有关通过 Microsoft Graph SDK 使用托管标识的文章。创建自动化帐户后，托管标识需要以下应用程序权限：

• GroupMember.ReadWrite.All（管理组成员身份）
• Group.Create（创建组）
• User.ReadWrite.All（管理组成员身份）
• Group.ReadWrite.All（管理组）
• Directory.ReadWrite.All（管理目录设置和生命周期策略）
• Sites.FullControl.All（管理站点设置）

注意：上述权限有一些重叠，特别是“Directory.ReadWrite.All”，但我已经包含了每个任务的最低权限，以便可以轻松地为您的脚本修改它们。 Directory.ReadWrite.All 权限是高特权权限级别，目前这是将组添加到组生命周期策略的要求。这并不理想，但在提供更细粒度的权限之前，这是通过 Microsoft Graph 实现此目的的唯一方法。

我们还需要以下“Office 365 SharePoint Online”权限：

• Sites.FullControl.All（允许 PNP 访问）

以下脚本使用 Microsoft.Graph PowerShell 模块将上面列出的权限分配给服务主体：

##List Required Permissions
$Permissions = @(
 "“GroupMember.ReadWrite.All"”
 "“User.ReadWrite.All"”
 "“Group.ReadWrite.All"”
 "“Directory.ReadWrite.All"”
 "“Sites.FullControl.All"”
 "“Group.Create"”
)
##Add Managed Identity ID
$MIID = "“<Replace with Managed Identity Service Principal ID>"”
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "“AppId eq '‘00000003-0000-0000-c000-000000000000'’"” # Microsoft Graph
[array]$Roles = $GraphApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
 $AppRoleAssignment = @{
 "“PrincipalId"” = $MIID
 "“ResourceId"” = $GraphApp.Id
 "“AppRoleId"” = $Role.Id
 }
 # Assign the Graph permission
 New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}
##List Required Permissions
$Permissions = @(
 "“Sites.FullControl.All"”
)
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "“AppId eq '‘00000003-0000-0ff1-ce00-000000000000'’"” # SharePoint Online
[array]$Roles = $GraphApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
 $AppRoleAssignment = @{
 "“PrincipalId"” = $MIID
 "“ResourceId"” = $GraphApp.Id
 "“AppRoleId"” = $Role.Id
 }
 # Assign the SharePoint permission
 New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}

我在此处给出的示例需要添加的权限（如图 1 所示），但重要的是要弄清楚您需要哪些 Microsoft Graph 权限并针对您自己的脚本进行调整。

接下来，自动化帐户需要安装所需的模块。本示例中使用了以下模块，但根据您的需要，请确保安装了正确的模块：

• Microsoft.Graph.Authentication
• Microsoft.Graph.Groups
• Microsoft.Graph.Identity.DirectoryManagement
• Microsoft.Graph.Teams
• 即插即用PowerShell
• Az.Accounts（这个应该已经安装在自动化帐户中）

创建脚本

对于任何可重用的自动化任务，您希望尽可能避免在代码中放置静态引用。这不仅是使脚本可重用的良好实践，而且还可以帮助其他人重用和构建您的脚本。这是通过在运行时传递的代码中构建参数来完成的。在此脚本,中，我定义了以下输入参数：

• SiteURL - 这是关联的 SharePoint 网站的相对 URL。它用于填充组的邮件昵称，然后用于生成站点 URL。
• AdminURL - 这是您的 SharePoint Online 实例的管理 URL。
• GroupName - 这是为团队创建的组的名称。
• GroupDescription - 这是组的描述值。
• DefaultOwner1 - 这是站点的所有者。
• DefaultOwner2 - 由于我们至少需要两个所有者，因此这是第二个所有者。
• InternalOnly - 这是一个布尔值，用于定义站点是否仅限内部 - 将其设置为 false 将允许外部访问该站点。稍后会详细介绍这一点。

Param
(
 [Parameter (Mandatory= $true)]
 [String] $SiteURL,

 [Parameter (Mandatory= $true)]
 [String] $adminURL,

 [Parameter (Mandatory= $true)]
 [String] $GroupName,

 [Parameter (Mandatory= $true)]
 [String] $GroupDescription,

 [Parameter (Mandatory= $true)]
 [String] $DefaultOwner1,

 [Parameter (Mandatory= $true)]
 [String] $DefaultOwner2,

 [Parameter (Mandatory= $true)]
 [bool] $InternalOnly
)

下一个关键区域是使用自动化帐户的托管标识连接到 Microsoft Graph。目前，这需要使用 Get-AzAccessToken cmdlet 来获取令牌，然后将其传递给 Connect-MgGraph cmdlet。连接后，我们切换到 beta 端点以允许进行目录设置配置，这在 v1.0 中不可用。要在本地测试此代码，您需要在计算机上安装 Microsoft.Graph、AZ 和 PNP.PowerShell 模块。

##Connect to Azure to retrieve an access token
Connect-AzAccount -Identity
$Token = (Get-AzAccessToken -ResourceURL "https://graph.microsoft.com").token

##Connect to Microsoft Graph
Connect-MgGraph -AccessToken $Token
select-mgprofile beta

创建组时，我们使用上面声明的参数变量来构建请求正文并将其传递给 New-MgGroup cmdlet。然后将脚本暂停 60 秒，以便在继续之前有时间完全创建组。这是避免错误的基本方法，主要是为了帮助您入门。在将您自己的解决方案投入生产之前，值得添加一些更强大的错误处理。组的主体包含基本组设置，并且可以针对您可能拥有的任何用例进行自定义。

##Build Parameters for new M365 Group
$GroupParam = @{
 DisplayName = $GroupName
 description = $GroupDescription
 GroupTypes = @(
 "Unified"
 )
 SecurityEnabled = $false
 IsAssignableToRole = $false
 MailEnabled = $false
 MailNickname = $SiteURL
 "Owners@odata.bind" = @(
 "https://graph.microsoft.com/v1.0/users/$DefaultOwner1",
 "https://graph.microsoft.com/v1.0/users/$DefaultOwner2"
 )
}

#Provision M365 Group
$Group = New-MgGroup -BodyParameter $GroupParam

##Wait for Group to finish provisioning
start-sleep -seconds 60

接下来，我们按照相同的流程为创建的组启用团队。这又可以根据您的需求进行定制。例如，我选择创建一个名为“欢迎！”的频道。对于每个团队。这是一个非常简单的示例，但可以使用自定义频道/频道消息等进行扩展，以构建特定的团队布局和自定义。

##Build Parameters for new Team

$TeamParam = @{
 "Template@odata.bind" = "https://graph.microsoft.com/v1.0/teamsTemplates('standard')"
 "Group@odata.bind" = "https://graph.microsoft.com/v1.0/groups('$($Group.id)')"
 Channels = @(
 @{
 DisplayName = "Welcome!"
 IsFavoriteByDefault = $true
 }
 )
 MemberSettings = @{
 AllowCreateUpdateChannels = $false
 AllowDeleteChannels = $false
 AllowAddRemoveApps = $false
 AllowCreateUpdateRemoveTabs = $false
 AllowCreateUpdateRemoveConnectors = $false
 }
}

##Add Team to group
New-MgTeam -BodyParameter $TeamParam

我还选择将团队添加到租户的团体生命周期政策中。如果您的策略是为所有组配置的，则不需要这样做，但许多组织希望从生命周期策略中排除关键组。由于策略中没有可用的排除参数，因此需要在创建组时添加该参数。

##Add Group to tenant group lifecycle policy
Add-MgGroupToLifecyclePolicy -GroupLifecyclePolicyId (Get-MgGroupLifecyclePolicy).id -GroupId $Group.id

最后，如果团队应仅在内部可用（基于IsInternal参数），我们应用 Azure AD 目录设置来阻止添加来宾用户，并使用 PNP 将站点共享设置配置为阻止外部共享数据。

##If the Team is internal only, block guest access and external sharing
if($InternalOnly){

##Block Guest Access to Group if required
$Template = Get-MgDirectorySettingTemplate | ?{$_.displayname -eq "Group.Unified.Guest"}

$TemplateParams = @{
 TemplateId = "$($template.id)"
 Values = @(
 @{
 Name = "AllowToAddGuests"
 Value = "false"
 }
 )
}
New-MgGroupSetting -BodyParameter $TemplateParams -GroupId $Group.id

##Connect to PNP
Connect-PnPOnline -ManagedIdentity -Url $adminURL

##Set Sharing policy to internal only
$site = Set-pnptenantsite -SharingCapability Disabled -Url $url

}

使用不同的输入参数，每个团队的确切配置都是完全可定制的。这是一个简单的内部/外部团队示例，但它应该让您了解如何构建脚本以允许不同的团队选项。

运行脚本

通过 Azure 自动化运行脚本非常简单，并会在运行时提示输入参数（图 2）。

验证团队

脚本完成后，将配置一个新团队，其中已定义设置并可供使用。检查 SharePoint Online（如图 3 所示），我们发现该网站已被限制为仅允许内部共享文件。

签入 Teams 后，团队将使用所提供的设置进行配置，并显示“欢迎！”通道存在（如图4所示）

最后，外部来宾无法添加到团队中，显示目录设置已成功应用（如图5）

自动化团队创建

只需付出相对少量的努力，即可自动配置组织中的 Teams，以满足业务和 IT 的需求。直接从 Azure 自动化运行脚本很好，但向前迈出一步并研究触发 Runbook 的不同方法，可以让组织在如何构建此流程方面发挥创意。核心脚本就位后，为什么不从 ITSM 工具触发 Runbook？或者来自 PowerApp？使用 Webhook 并从您选择的应用程序调用它，同时传递所需的参数，可以非常轻松地完成此操作。可以在 Azure 自动化中创建 Webhook，如图 6 所示。本系列将更详细地讨论如何使用 Azure 自动化来处理 SharePoint Online。

我在这里给出的非常简单的示例可以在 GitHub 上找到，并且几乎不包含错误处理和优化的内容。不过，在开发自己的流程时，这是一个很好的起点，并且推动 Teams 提供自动化流程可以提供更多开箱即用的控制。

Microsoft 平台迁移规划和整合

简化迁移规划，克服迁移挑战，更快地完成项目，同时最大限度地降低成本、风险和对用户的干扰。