通过 Get-ExoMailbox Cmdlet 使用过滤器

升级脚本时需要考虑的一些复杂性

上个月，我写了一篇有关升级 Exchange Online PowerShell 脚本以使用 Get-ExoMailbox cmdlet 而不是旧版 Get-Mailbox 对应项的文章。我提出的原因之一是 Get-ExoMailbox 检索邮箱数据的速度更快，这导致了一些关于总体性能的问题。获取几个邮箱的数据很容易（而且很快），但是一旦您需要处理数百或数千个邮箱，优化就很重要。

过滤数据

这让我想到了过滤器的主题。通常只需要处理租户中可用的全套邮箱中的几个邮箱。过滤器应用 PowerShell 的条件来选择正确的邮箱。过滤器越好，您获得所需邮箱的速度就越快。

过滤器有两种变体：服务器端和客户端。服务器端意味着从服务器返回的数据经过过滤并准备就绪。客户端意味着数据从服务器传来并在客户端进行过滤。一般来说，为了获得最佳性能，黄金法则是尽可能使用服务器端过滤。

当 Filter 参数将对邮箱属性的查询传递到服务器时，就会发生服务器端筛选。 Exchange PowerShell 支持多种可与其 cmdlet 一起使用的可筛选属性。例如，此命令返回 Office 属性设置为 Dublin 的邮箱。

Get-ExoMailbox -Filter {Office -eq "Dublin"}

等效的客户端过滤器获取所有邮箱并将集合通过管道传输到 Where 命令以过滤出所需的邮箱：

Get-ExoMailbox | Where-Object {$_.Office -eq "Dublin"}

乍一看，您会期望此代码能够工作，因为该方法适用于 Get-Mailbox。从理论上讲，它不应该，因为 Office 属性不在 Get-ExoMailbox 返回的默认属性集中。请记住，REST cmdlet 比远程 PowerShell cmdlet 更快的部分原因是它们返回的属性数量减少。但是，无论出于何种原因，该代码都会返回邮箱集，其中 Dublin 是 Office 属性的值，即使返回的数据包含 Office 属性的空白值也是如此。这很奇怪。

为了使我们的代码正常工作，我们必须告诉 Get-ExoMailbox 获取 Office 属性。

Get-ExoMailbox -Properties Office | Where-Object {$_.Office -eq "Dublin"}

使用服务器端筛选时，您不必担心指定属性，因为 Exchange 在服务器上应用筛选器。属性限制仅适用于返回给客户端的数据。

请记住，其他参数也会导致服务器上发生过滤。将这些参数组合在一起可以创建更精确的查询。在此示例中，我们添加RecipientTypeDetails参数来指示 Exchange Online 仅返回用户邮箱：

Get-ExoMailbox -Properties Office -RecipientTypeDetails UserMailbox | Where-Object {$_.Office -eq "Dublin"} 

指定要返回的对象数量也是过滤器的另一种形式：

Get-ExoMailbox -Properties Office -RecipientTypeDetails UserMailbox -ResultSize 100 | Where-Object {$_.Office -eq "Dublin"} 

关键点是从服务器请求数据时尽可能具体。这将加快处理速度，并意味着您无需在信息到达客户端时丢弃信息。

过滤器不一致

新 cmdlet 的服务器端筛选方式存在一些不一致之处。例如，您需要小心使用通配符。微软的文档说：

-like 和 -notlike 运算符在使用通配符 (*) 方面受到限制。具体来说，您只能在字符串值的开头、字符串值的末尾或两者都使用通配符。

这段文字让您看起来可以执行如下命令：

Get-Mailbox -Filter {DisplayName -Like "*Tony*"}

并将其升级为使用 Get-ExoMailbox 代替：

Get-ExoMailbox -Filter {DisplayName -Like "*Tony*"}

但是该命令因无效的过滤子句而失败，这证明即使 Microsoft 文档中的声明保证某些功能应该有效，也需要进行测试。

逆转建议

多年来，人们一直采用黄金法则来使用服务器端过滤来获取邮箱数据。但正如我们刚刚看到的，基于 REST 的 cmdlet 的工作方式与旧版 cmdlet 不同。事实上，Exchange Online 开发团队发现新 cmdlet（包括 Get-ExoMailbox）的客户端筛选速度更快。微软表示，他们正在努力改进 cmdlet 的服务器端过滤。

经过一些测试后，微软断言的原因似乎是 Get-ExoMailbox 在查找邮箱时需要“预热”的方式。这包括准备结果分页、连接到邮箱服务器等。通过多次运行相同的查询可以很容易地看到预热的效果。第一次运行总是最慢的，此后运行速度要快得多，并且可以使用 Measure-Command cmdlet 多次运行命令来轻松验证。

然而，着眼于未来的性能改进，我不确定是否要遵循 Microsoft 的建议，通过 Get-ExoMailbox 使用客户端过滤。目前的性能损失似乎并不算太大，并且保留服务器端过滤可以避免将来进一步更改的需要。然而，这一理论必须在各个脚本的背景下进行测试。对于某些人来说，最好转换为客户端过滤，而对于其他人来说，最好的决定是保持原样。