Microsoft 365 中 PowerShell 脚本编写的挑战

模块退役、Cmdlet 更改和参数消失

俗话说“如果它有效，就不要修复它”，这在云计算领域并不完全正确。对于依赖 PowerShell 脚本和模块的业务流程，由于 Microsoft 对模块和 cmdlet 所做的更改，不主动维护代码很快就会成为问题。也就是说，除非组织对自动化工作中断没有任何问题，否则通常会在下个月的第一天造成不愉快的意外。

在本文中，我讨论了管理员在使用 PowerShell 脚本时可能遇到的一些挑战，与在精彩的 2023 年专家会议上举行的同名演讲相关。此外，我还提供了一些指导，并指出了一些可以帮助重写或重构代码的工具，即在保留其外部功能的同时更新代码。我的意思是保留需要调用代码的方式，例如保持参数相同。

意识

维护的一个复杂因素是一些组织不知道隐藏在其基础设施中的所有依赖项。例如，仍然存在大量依赖 PowerShell 脚本和模块的第三方解决方案。这些依赖项有结束日期。

以下是从客户那里听到的一些说法：

• 合作伙伴 X 实施了一项促进配置和许可的任务。我希望当我们需要做某事时他们会通知我们。
• 我读到 PowerShell 模块 X 将在 Y 日期被弃用。我们需要做些什么吗？
• 我们有一组 PowerShell 脚本来支持管理任务；我们从哪里开始？

我强调您应该采取积极主动的立场，而不是等到 Microsoft 弃用 PowerShell 模块之前的最后几周或在 Microsoft 推迟弃用时退缩。保持最新状态不仅适用于技术（在本例中为 PowerShell 模块），还适用于知识和技能。例如，了解 Microsoft Graph PowerShell SDK 的管理员数量很少。与此同时，微软在线服务和Azure AD模块都在走向退出，这一点已经被写在墙上几年了。

追踪变革的动机

那么，是什么导致管理员需要检查现有的脚本和工具呢？根据我的经验，除了优化和调整以适应其他业务流程的变化之外，还存在两个主要驱动因素：

1. 安全。最近的一个例子是 Exchange Online 中基本身份验证的弃用。此步骤要求管理员检查其脚本和工具，以检测基本身份验证的任何使用情况，并通过实施现代身份验证来更新它们。
   
   另一个示例是通过密码（秘密）和保存的凭据或 Microsoft 使用基于证书的身份验证365 在某个时候开始要求 TLS 1.2。在某些情况下，此类更改会导致在客户端实施更改。
   
2. 生命周期。 PowerShell 模块有生命周期。因此，密切关注那些可能影响您的组织的模块的更改（例如它们的生命周期）至关重要。当前的示例是 Microsoft Online Services 和 AzureAD 模块，两者均将于 2024 年 3 月 30 日最终停用。
   
   此外，模块可能与底层操作系统或较新的 PowerShell 版本不兼容。例如，PowerShell v7 不支持 AzureAD 和 Microsoft Commerce 模块，如果您想使用管道并行化等 PowerShell v7 功能，就会陷入困境。是的，您可以使用 Import-Module 和 UseWindowsPowerShell 开关以兼容模式导入它，但这很快会导致意外问题。

模块内务管理

为了使模块在本地客户端或服务器上保持更新，社区中可用的多个脚本可能有助于完成此任务。 Connect-Office365Services 包含用于报告和更新一组固定的与 Office365 工作负载相关的 PowerShell 模块的辅助函数。在当前会话中加载脚本或通过点源 ([PS]>. .\Connect-Office365Services.ps1) 通过 PowerShell 配置文件加载脚本后，使用 Report-Office365Modules 报告可供更新的候选模块，或使用 Update -Office365模块来更新它们。 请注意，要检查并安装预览模块，您需要指定AllowPrerelease开关。或者，使用脚本协助更新 Tony Redmond 发布的模块：UpdateOffice365PowerShellModules.ps1。

当涉及作为 Azure Function 或 Azure Runbook 的一部分运行的脚本时，它们也具有依赖关系。这意味着相同的审核过程也适用于该代码。请注意，在 Azure 中更新模块的方法略有不同，如此处所述。

在线交流

Exchange Online 管理模块版本 3 (v3) 模块是用于通过 PowerShell 管理 Exchange Online 的当前版本。 v2 模块的 GA 版本仍然存在，但不推荐使用。它不仅依赖于 PowerShell 远程处理的客户端 WinRM（需要启用基本身份验证），而且自 2022 年 9 月以来 v2 也停止接收更新。在 Microsoft 365 中发生的持续变化中，这听起来像是一生。一个有趣的事实是，v3 模块最初是作为 v2 预览模块开始的，该模块之前阻止了具有“生产中无预览”政策的组织使用它。

下面显示了更新现有 Exchange 代码的简化示例，该代码也可以是您针对本地 Exchange 使用的脚本的一部分。此处，需要修改用于连接到 Exchange 的脚本中的命令以使用现代身份验证，其中涉及指定为此目的在 Entra ID 中注册的应用程序生成的租户和应用程序 ID，以及配置为潜在身份验证方法的证书或机密与注册的应用程序。此外，与 Exchange 相关的命令（例如 Get-Mailbox）可能会替换为基于 REST 的 Get-EXOMailbox 以及一些其他代码更改，以便从 REST 的性能优势中获益。支持 Get-Mailbox cmdlet。

Exchange 在线管理 v3

Connect-ExchangeOnline
-组织 ..onmicrosoft.com
-AppId .. -CertificateThumbprint ..

获取-EXO邮箱。

入口ID

用于管理 Entra ID 的模块面临的挑战类似于管理 Exchange Online，但有所不同。对于 Entra ID，有两个旧模块可用：Microsoft Online Services (MSOnline) 和 AzureAD。第一个自 Office 365 的前身 Business Productivity Online Suite (BPOS) 诞生以来就已经存在。后者在 2016 年迎来了曙光，成为 PowerShell 可管理的 PowerShell 模块（MSOnline 过去需要安装）以及 Office 365 中 API 的更改。由于 AzureAD 从未提供与 MSOnline 相同的完整功能，因此两者仍然存在。许多脚本、产品和文档（甚至是由 Microsoft 编写的）仍然引用这些模块。即使是 Microsoft 支持部门仍然会分发基于 MSOnline 和 AzureAD 模块的说明。这些脚本和指令很快就会变得不准确且无法运行。

这些模块的日子已经屈指可数了，因为用于与 Entra ID 交互的底层库和 API 将被淘汰。实际停用日期现定为 2024 年 3 月 30 日，此前微软多次推迟了这一日期，以便为供应商和组织提供更多时间来进行必要的更改。这些模块中的 cmdlet 用于分配 Office 365 许可证的许可 API 已于 2023 年 9 月 30 日停用。

Microsoft 平台迁移规划和整合

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

拥抱图表

Microsoft 正在推动组织和供应商采用 Microsoft Graph PowerShell SDK，而不是 MSOnline 和 AzureAD，这是一组提供与 Microsoft Graph 对话的 cmdlet 的 PowerShell 模块。但是，MSOnline 和 AzureAD 模块在 Entra ID 空间中提供“一揽子”权限，而 Graph 则需要更细粒度的规范权限。管理员可能需要了解他们可能不熟悉的概念，例如权限范围或何时使用高级查询。此外，当与用于生产力使用的常规端点（v1）或测试版进行通信时，Graph 的端点是分离的，它提供了最新的开发成果，但不适用于生产用途。

与使用新式身份验证更新 Exchange Online 的代码类似，相同的原则也适用于 MSOnline 和 AzureAD 脚本和工具。此处，语句需要更新为 Microsoft Graph PowerShell SDK，该 SDK 与 Microsoft Graph 进行通信，而不是两个模块使用的即将弃用的 Azure Active Directory 身份验证库 (ADAL) 和 Azure AD Graph API。

让事情变得有点复杂的是，Microsoft Graph PowerShell SDK 最近将其模块一分为二（V1.0 或生产版和测试版），并且两个端点都有自己的模块。这给已经使用 PowerShell Graph SDK 的管理员带来了一个小障碍，因为他们必须检查代码。我的观点是，它还表明，当您最终转向使用 PowerShell Graph SDK 时，您仍然会偶尔面临相同的挑战。

指南和工具

阅读上面的内容，人们可能会认为这是一个简单的查找替换操作的问题。对于较小的存储库来说可能是这样，但在处理大量脚本和工具时，更倾向于方法论的方法。

检查 Exchange 相关代码的一种方法是使用我最初开发的脚本来检查脚本是否使用基本身份验证，Analyze-ExoScript。它将 Exchange Online 管理模块中包含的命令与一个或多个脚本进行比较。为此，它利用称为抽象语法树的东西来解释代码，允许您执行智能操作，例如输出仅 Exchange 命令、显示 Connect-ExchangeOnline 与 Credentials 参数结合使用的位置，或指示基于 REST 的命令可以在何处使用出于性能原因考虑。我在这里写了这个过程。

Microsoft 仅提供将基于 MSOnline 和 AzureAD 的脚本转换为 PowerShell Graph SDK 的全局指南。幸运的是，社区并没有坐以待毙。 Microsoft 员工 Merill Fernando（Entra 的首席产品经理）开发了一个在线 Graph PowerShell 转换分析器。该网站可用于通过复制和粘贴代码来协助将 MSOnline 和 AzureAD 命令转换为其 Microsoft Graph PowerShell SDK 对应命令。此外，分析还包含执行相关 Microsoft Graph PowerShell SDK cmdlet 所需的范围权限。

如果转换分析器由于其交互性质而适合一次性使用，则 PowerShell Azure 迁移顾问（或只是 PSAzureMigrationAdvisor）可以分析一组脚本，类似于前面提到的 Exchange 分析脚本。 PSAzureMigrationAdvisor 是必须安装在工作站上的 PowerShell 模块。然后，您可以让它分析脚本，例如，

获取子项 C:\ADScripts |读取 AzScriptFile。此命令输出已处理的脚本，其中哪一行包含 MSOnline 或 AzureAD 命令及其对应命令（图 1）。这表明了“问题”有多大，但也可以作为一个清单，在与团队一起更新较大的存储库时很有帮助。

人工智能的承诺

ChatGPT 或 Copilot for GitHub 能否在此转换练习中发挥任何作用？答案是“视情况而定”。首先，有一个肯定的答案，因为与分析工具一样，Copilot 可以帮助您快速分析脚本并创建转换的初始草案。那么答案是否定的，因为人工智能产生的输出仍然需要由智能人进行代码审查和测试，并且可能需要一些调试。这是因为人工智能有时会犯错误。一个例子是一个简单的方程 $var eq ‘string’，当 ChatGPT 要求生成 PowerShell 代码时，它会提出这个方程，但由于“eq”不是 PowerShell 运算符（-eq 是），因此该代码将无法工作。然而，人工智能的发展不会停滞不前，因此建议定期查看这些人工智能解决方案。当然，当你让人工智能执行这项任务时，学习新技能的效果就不存在了。

结论

您可能认为使用 PowerShell 维护脚本和进程是一项繁重的工作。说实话，确实可以。像“真正的开发人员”一样，管理员应该计划和执行代码审查周期，以适应其代码所依赖的模块和接口的变化。对脚本和工具及其依赖关系和连接性有一个很好的概述可能会加速代码审查的工作，并有助于发现外部更改的后果。

管理员，请对您的代码采取积极主动的立场并预见未来的变化；尽可能更新脚本和工具，而不是必须更新，这样时间和资源就会变得稀缺。