将 GitHub Copilot 与 Microsoft 365 PowerShell 结合使用

用于 PowerShell 开发的 AI 援助是否值得每月 10 美元？

你们中的一些人可能已经注意到，我喜欢编写 PowerShell 来自动化 Microsoft 365 操作。在过去的几年中，我在 Office 365 for IT Pros GitHub 存储库中积累了相当多的脚本。我不是专业的开发人员，编写代码一直是一件偶然的事情，尤其是在学习新的 cmdlet（例如 Microsoft Graph PowerShell SDK 中的数千个）时。几个月前，Andy Schneider 报告使用 GitHub Copilot 升级脚本以使用 Microsoft Graph PowerShell SDK 取得了良好的结果。鉴于我经常使用 SDK，一切都表明这是一个非常值得尝试的工具，这就是我在过去四个月里一直在做的事情。

GitHub Copilot 个人许可证的价格为每月 10 美元，这笔投资是理所当然的。 GitHub 表示，预测文本可以帮助开发人员更快地完成任务 55%。换句话说，人工智能应该可以帮助我节省 30 分钟的时间来编写通常需要一个小时才能编写的脚本。这应该可以释放喝咖啡的时间。我使用 Copilot 与 Visual Studio Code 的集成，效果非常好。

副驾驶基础知识

GitHub Copilot 遵循与其他 Microsoft Copilot 相同的方法。用户通过应用程序（如 Visual Studio Code）进行交互以输入提示。提示告诉 GitHub Copilot 要做什么。因为我们正在处理代码，所以提示涵盖了创建函数或编写脚本或程序等内容。 GitHub Copilot 根据其大型语言模型 (LLM) 处理提示。

GitHub 使用存储在公共 GitHub 存储库和其他公开资源中的自然语言文本和代码来培训法学硕士。这很重要，因为这意味着 GitHub Copilot 在能够处理大量已知代码时表现出色。例如，图 1 中所示的提示要求 GitHub Copilot 创建一个 PowerShell 函数来格式化字节大小并以 KB、MB 或 GB 为单位输出大小。

类似的函数之前可能已创建过多次（例如脚本中用于创建有关 OneDrive for Business 帐户中的文件的报告的函数），因此 GitHub Copilot 可以轻松处理生成 Convert-BytesToSize 的提示 功能：

function Convert-BytesToSize {
    param (
        [Parameter(Mandatory = $true)]
        [long]$Bytes
    )

    $Kilobytes = $Bytes / 1KB
    $Megabytes = $Bytes / 1MB
    $Gigabytes = $Bytes / 1GB

    if ($Gigabytes -ge 1) {
        return "{0:N2} GB" -f $Gigabytes
    }
    elseif ($Megabytes -ge 1) {
        return "{0:N2} MB" -f $Megabytes
    }
    elseif ($Kilobytes -ge 1) {
        return "{0:N2} KB" -f $Kilobytes
    }
    else {
        return "{0:N2} bytes" -f $Bytes
    }
}

能够在几秒钟内创建这样的功能，令人印象深刻地展示了人工智能在经过训练后可以做什么。正如我们将看到的，当被要求处理 API 时，可用于训练法学硕士的示例较少，它就不那么令人印象深刻了。对于一些最新的 Microsoft Graph API 来说尤其如此。

例如，微软最近更新了 Planner Graph API 以支持应用程序权限。已发布的使用 Planner Graph API 的示例并不多。 Practical365.com 有一些文章和示例脚本，例如从 Microsoft 365 管理中心同步任务和不完整的任务分析。然而，尽管这些脚本存储在 GitHub 中，但当 GitHub 构建其 LLM 时，它们和其他示例可能并不存在。

LLM 处理提示后，GitHub Copilot 将其结果返回给应用程序。用户可以接受或删除该代码并重试，直到生成的代码令人满意为止。

毫无疑问，GitHub Copilot 可以很好地处理一些日常任务，例如在代码中插入注释。它还可以像登录用户一样快速学习编码。例如，我以 GitHub Copilot 非常乐意复制的特定方式使用 Write-Host 命令。

但复制某人的风格或填写评论并不是魔法。 GitHub Copilot 为在多个平台上使用多种语言进行编写的开发人员提供服务。 PowerShell 只是其中一种语言，而 Microsoft 365 PowerShell 则是平台之一。让我们看看将 GitHub Copilot 与您希望使用的那种 PowerShell 结合使用来自动化 Microsoft 365。

GitHub Copilot 和 Microsoft 365

我决定要求 GitHub Copilot 编写一个函数来报告 Entra ID 帐户的上次登录日期。图 2 显示了 GitHub Copilot 生成的提示和函数。

从表面上看，代码看起来令人印象深刻。但这并不是因为它使用了获取用户活动图 API，该 API 旨在检索应用程序内的活动详细信息。简而言之，这个功能是行不通的。

所有生成式人工智能工具的成功使用取决于用户提交处理的提示的完整性。人工智能并没有失败：我只是不够精确，人工智能无法弄清楚我想要什么。因此，我再次尝试使用此提示：

编写一个函数，根据 Entra ID 登录日志返回 Entra ID 用户帐户的上次成功登录日期

图 3 显示了结果。同样，代码看起来不错，但同样，它不起作用。

这次的问题是 GitHub Copilot 产生了一点幻觉，创建了一个不存在的名为 Get-EntraIDSignInLogs 的 cmdlet 或函数。也许它存在于 GitHub 存储库中的某个地方，但这对我来说没有好处。

此时，您可能会认为我对 GitHub Copilot 生成代码的能力非常挑剔。我不是。该代码具有结构并指示返回所需结果所需的流程，因此很有帮助。问题可能是 Copilot 在其大型语言模型中没有足够的信息来提出该人考虑的两种解决方案中的任何一种：

• 使用为 Entra ID 用户帐户记录的上次成功登录日期。
• 使用 Entra ID 登录日志查找用户上次成功的登录事件。对登录日志的编程访问需要 Entra ID P1 许可证。

利用 GitHub Copilot 生成的结构，我可以插入一些代码来查询 Entra ID 登录日志并完成工作。已有结构可以节省一些时间。也许不足以喝一杯咖啡，但肯定需要几分钟。

手工编写的人工代码使用 Get-MgAuditLogSignIn cmdlet 查找用户的最后三个登录事件，然后从集合中提取第一个成功登录以返回该事件的时间戳。

function Get-LastSuccessfulSignInDate {
    param (
        [Parameter(Mandatory = $true)]
        [string]$UserId
    )
    $StartDate = Get-Date (Get-Date).AddDays(-14) -format 'yyyy-MM-dd'
    $EndDate = (Get-Date -format 'yyyy-MM-dd')
    
    # Retrieve the first three sign-in logs for the specified user account
    [array]$SignInRecords = Get-MgAuditLogSignIn -Filter "createdDateTime gt $StartDate and createdDateTime lt $EndDate and UserId eq '$UserId'" -Top 3 -Sort "createdDateTime DESC"

    # Make sure that we have successful
    $LastSignInRecord = $SignInRecords | Where-Object {$_.Status.errorcode -eq 0} | Select-Object -First 1

    # Return the date of the last successful sign-in
    if ($LastSignInRecord) {
        return $LastSignInRecord.CreatedDateTime
    } else {
        return $null
    }
}

在线交换示例

Exchange PowerShell 自 2006 年底就已推出，因此 GitHub 存储库中保存了大量 Exchange 脚本。我要求 GitHub Copilot“查找主电子邮件地址属于特定域的所有 Exchange Online 用户邮箱”。 GitHub Copilot 回复如下：

$domain = "example.com"
$mailboxes = Get-EXOMailbox -Filter "EmailAddresses -like '*@$domain'"

foreach ($mailbox in $mailboxes) {
    # Do something with each mailbox
    Write-Output $mailbox.UserPrincipalName
} 

如果您使用域名更新 $domain 变量，则该代码将起作用。但是，它的代码很差，因为它没有按请求过滤用户邮箱，而是根据 EmailAddresses 属性而不是主 SMTP 地址进行过滤。无论如何，这肯定是值得使用的东西。

Exchange Online 管理员多年来一直编写脚本来报告邮箱大小。我最近讨论了这个主题，所以这似乎是对 GitHub Copilot 的一个很好的测试。这是我使用的提示：

编写一个 PowerShell 脚本来查找所有 Exchange Online 用户邮箱并报告每个邮箱的项目数和总项目大小（以 MB 为单位）

GitHub Copilot 生成了以下脚本：

# Connect to Exchange Online
Connect-ExchangeOnline

# Get all user mailboxes
$mailboxes = Get-Mailbox -ResultSize Unlimited

# Iterate through each mailbox
foreach ($mailbox in $mailboxes) {
    $mailboxName = $mailbox.DisplayName
    $itemCount = (Get-MailboxStatistics -Identity $mailboxName).ItemCount
    $totalItemSize = (Get-MailboxStatistics -Identity $mailboxName).TotalItemSize.Value.ToMB()

    Write-Host "Mailbox: $mailboxName"
    Write-Host "Number of Items: $itemCount"
    Write-Host "Total Item Size: $totalItemSize MB"
    Write-Host "------------------------"
}

这是一个非常基本的脚本，看起来似乎可以完成这项工作，但实际上并没有。 Get-MailboxStatistics cmdlet 没有 ToMB 方法，因此每个邮箱的脚本都会失败，并出现以下错误：“方法调用失败，因为 [Deserialized.Microsoft .Exchange.Data.ByteQuantifiedSize] 不包含名为“ToMB”的方法。”

关于生成的脚本最好的说法是它可以作为某人解决问题的起点。但考虑到已经编写了这么多脚本来解决这个问题，我对 GitHub Copilot 没有产生更好的结果感到失望。

总的来说，GitHub Copilot 是值得的

与任何生成式人工智能一样，你不能假设人工智能创造的任何内容都是准确且有用的。正如我们所看到的，GitHub Copilot 生成的代码并不总是有效，当它有效时，可能需要调整代码才能达到所需的结果。

这可能是处理 Microsoft 365 模块中的 PowerShell cmdlet 所特有的问题，因为我没有看到通用 PowerShell 存在相同的问题。如果有更好的提示，我生成良好代码的成功率也可能会提高。

我能给出的最好建议是，如果您尚未使用 GitHub Copilot，则应该尝试一下。我怀疑，如果我是一名专业开发人员，我会从 GitHub Copilot 中发现更多价值。目前，我对 AI 提供的帮助感到满意，并认为每月 10 美元非常值得。随着时间的推移，GitHub Copilot 为 Microsoft 365 生成良好 PowerShell 代码的能力可能会提高，然后价格就会看起来很便宜。