Microsoft 365 PowerShell 的混乱状态

图 API 和工作负载模块争夺霸权

一些精明的观察家问，为什么 Microsoft 有两项明显并行的工作来支持 Microsoft 365 中的 PowerShell。一方面，Teams、Exchange Online 和 SharePoint Online 等开发团队主要针对特定于应用程序的模块。另一方面，Microsoft Graph PowerShell SDK 旨在为所有支持的工作负载中的所有 Graph API 启用 PowerShell。

我所说的支持的工作负载是指支持图形 API 的工作负载。有些应用程序（例如 Teams）专门使用图表。其他应用程序（例如 Exchange Online 和 SharePoint Online）支持混合 API。例如，可以使用 Outlook Graph API，但没有可用于自动执行 Exchange 管理操作的 Graph API，因此在执行邮箱管理等任务时，Graph API 中存在真空。

这种二分法是由多种因素造成的。 Exchange 和 SharePoint 在本地和云中运行，因此它们需要在这两个平台上支持 PowerShell。 Teams 是一个纯云应用程序，因此它很自然地关注图。可以选择使用哪个模块可能会被认为是件好事，但这也令人困惑，特别是对于那些不习惯处理 Microsoft 365 PowerShell 选项的人来说。

比较 Teams 工作负载模块和 SDK

作为我的意思的一个示例，让我们看一下代码的两个实现，用于创建在租户中创建的所有 Teams 通道的报告。我选择 Teams 模块是因为它基于 Graph，所以代码和结果应该非常相似。

从概念上讲，创建报告的步骤很简单：

• 获取团队集。
• 对于每个团队，获取一组通道。
• 对于每个频道，报告您发现的内容。

以下是为 Teams PowerShell 模块编写的执行该作业的脚本代码：

Connect-MicrosoftTeams
$TeamsChannelData = [System.Collections.Generic.List[Object]]::new() 
[array]$Teams = Get-Team
ForEach ($Team in $Teams) {
   Write-Host "Processing team" $Team.DisplayName
   $Channels = Get-TeamChannel -GroupId $Team.GroupId
    ForEach ($Channel in $Channels) {
     $ReportLine  = [PSCustomObject] @{  
         Team     = $Team.DisplayName 
         Channel  = $Channel.DisplayName
         Type     = $Channel.MembershipType
         Id       = $Channel.Id }
       $TeamsChannelData.Add($ReportLine) }
}
$AvgChannels = [math]::round(($TeamsChannelData.Count/$Teams.Count),2)
Write-Host ("{0} Teams found with {1} channels, an average of {2} channels per team" -f $Teams.Count, $TeamsChannelData.Count, $AvgChannels)

这里没有特别的酱汁。该代码生成每个团队中的渠道以及渠道类型（常规、共享或私有）的报告。图 1 显示了输出（对于图形版本）。

现在让我们看看适用于 Microsoft Graph PowerShell SDK 中的 cmdlet 的相同代码。发生相同的步骤：

Connect-MgGraph
$TeamsChannelData = [System.Collections.Generic.List[Object]]::new() 
[array]$Teams = Get-MgGroup -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')" -All 
ForEach ($Team in $Teams) {
   Write-Host "Processing team" $Team.DisplayName
   $Channels = Get-MgTeamChannel -TeamId $Team.Id
    ForEach ($Channel in $Channels) {
     $ReportLine  = [PSCustomObject] @{  
         Team     = $Team.DisplayName 
         Channel  = $Channel.DisplayName
         Type     = $Channel.MembershipType
         Id       = $Channel.Id
         Created  = $Channel.CreatedDateTime
         SPOUrl   = $Channel.AdditionalProperties['filesFolderWebUrl']
       }
       $TeamsChannelData.Add($ReportLine) }
}
$AvgChannels = [math]::round(($TeamsChannelData.Count/$Teams.Count),2)
Write-Host ("{0} Teams found with {1} channels, an average of {2} channels per team" -f $Teams.Count, $TeamsChannelData.Count, $AvgChannels)

您可能会注意到为 Teams 模块编写的代码存在以下差异：

• Get-MgGroup cmdlet 应用筛选器来查找支持团队的 Microsoft 365 组。在另一个脚本中，Get-Team cmdlet 仅处理团队，因此不需要过滤器。由于工作负载模块不需要过滤对象，因此在查找要处理的信息时通常更容易处理。
• 输出到报告的渠道信息包括一些 Get-TeamChannel cmdlet 无法使用的数据。我选择输出每个频道的创建日期以及 SharePoint Online 团队网站中频道文件夹的 URI。我们从中了解到，图形 API 通常会公开比通过工作负载模块中的 cmdlet 提供的更多有关对象的信息。开发人员选择要公开的信息，在这种情况下，开发人员可能会决定没人想知道通道或其 SharePoint URI 的创建日期。

模块性能

从上面的证据来看，很明显，使用 Microsoft Teams 模块或 Graph SDK 编写脚本将使用类似的代码提供类似的结果。但就性能而言，一种方法比另一种方法更好吗？

一种测试方法是多次运行代码，并使用 PowerShell 的 Measure-Command cmdlet 报告代码运行所需的时间。我之前曾使用此技术来测试 Exchange Online REST cmdlet（例如 Get-ExoMailbox）在 2019 年推出后的性能。

以下是我使用 Microsoft Graph PowerShell SDK cmdlet 运行代码 10 次的方法：

Write-Host "Running Teams Test..."
$TotalSeconds = 0
For ($i=0; $i -lt 10 ) {
 $i++ ;  Write-Host "Processing run" $i
 $TeamsResult = Measure-Command { 
[array]$Teams = Get-MgGroup -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')" -All 
ForEach ($Team in $Teams) {
   # Write-Host "Processing team" $Team.DisplayName
   $Channels = Get-MgTeamChannel -TeamId $Team.Id
    ForEach ($Channel in $Channels) {
     $ReportLine  = [PSCustomObject] @{  
         Team     = $Team.DisplayName 
         Channel  = $Channel.DisplayName
         Type     = $Channel.MembershipType
         Id       = $Channel.Id
         Created  = $Channel.CreatedDateTime
         SPOUrl   = $Channel.AdditionalProperties['filesFolderWebUrl']
       }
       $TeamsChannelData.Add($ReportLine) }
} # End of ForEach Channel
$Total = $Total + $TeamsChannelData.Count
} # End of ForEach team
Write-Host ("Result: Processed channels from {0} teams in {1} seconds" -f $Teams.Count, $TeamsResult.TotalSeconds)} 
# End of 10 iterations

通过包含 179 个通道的 82 个团队测试代码，我发现：

• 使用 Graph SDK cmdlet 运行脚本需要 25 到 34 秒（图 2）。使用 Teams cmdlet 的脚本花费的时间是原来的两倍。
• Graph SDK cmdlet 报告了 179 个通道，而不是 Teams cmdlet 报告的 178 个。差异是因为 Get-MgTeamChannel 可以报告其他租户中托管的共享频道，而 Get-TeamChannel 会忽略这些频道。 Microsoft 可能会在 Microsoft Teams PowerShell 模块的未来版本中缩小这一差距。

我怀疑这里检测到的速度优势会随着要处理的团队数量的增加而增加。如果不去创建大约 1000 个团队，就很难知道这一点，但我愿意冒险说 Graph SDK cmdlet 在这种情况下表现更好，并且在其他情况下也可能会做同样的事情。当然，您的情况会有所不同，并且不能保证 Graph SDK cmdlet 在特定情况下会更快。

需要思考的问题

我运行的测试非常基本，但它们足以产生一些问题，您在为 Microsoft 365 创建下一个自动化脚本之前可能会考虑这些问题。两个基本问题是：

• 可以使用 Microsoft Graph PowerShell SDK 吗？如上所述，SDK 未覆盖 Microsoft 365 的某些部分，工作负载模块是唯一的选择。
• 速度重要吗？对于需要处理小数据集的小租户来说，它并不适用。当处理数千个对象（例如邮箱、组或团队）时，它变得至关重要。
• 特定方法是否允许访问在其他地方无法获得的数据？

之后，它归结为诸如对 cmdlet 的熟悉程度、可用作新脚本基础的现有代码的可用性、您是否计划以交互方式运行脚本或通过计划任务运行脚本等问题。如果您选择继续使用工作负载模块，那是完全可以的。至少，直到微软决定像 Azure AD 那样弃用某个模块。

多个 Microsoft 365 PowerShell 选项并不罕见

在 PowerShell 中通过多种方式完成任务并不罕见。过去，Azure AD 模块试图接管 Microsoft Online Services 模块，但在某些领域（例如 MFA 注册）从未完全成功。 SharePoint Online 模块中的 Cmdlet 通常与 PnP 模块结合使用来管理 SharePoint Online 和 OneDrive for Business。有时，您需要使用 Exchange Online cmdlet 来管理 Microsoft 365 组的元素，同时还需要使用 cmdlet 来管理 Teams（甚至 Azure AD）。 Microsoft 365 可能是 PowerShell 的混乱混合体，因此从这个角度来看，很高兴看到 Microsoft Graph PowerShell SDK 取得进展。它是在过去一年左右的时间里发生的。

为了让 Microsoft Graph PowerShell SDK 成为想要编写 PowerShell 脚本来处理 Microsoft 365 数据的开发人员的自然选择，我们需要做的是：

• 覆盖所有 Microsoft 365 工作负载，包括 Exchange Online。
• 更好的文档（包括好的示例）。
• 消除了 SDK 中存在的一些功能缺陷。
• 减少有时发生的摩擦（例如 Get-MgGroupMember 将组的成员资格信息作为一组标识符返回，而不是成员名称及其详细信息）。

从表面上看，这似乎并不多，但微软工程团队内部的紧张关系和其他软件工程优先事项可能意味着这种涅槃状态要到我退休后很久才会出现。即便如此，在客户租户和 Microsoft 本身中运行的大量脚本可能意味着 Microsoft 365 中 PowerShell 的混乱状态将持续数年。