使用 Get-AzureRmAutomationModule cmdlet 检索模块时全局模块的模块版本不一致答案

【问题标题】：Inconsistent module version for global modules when retrieving modules using Get-AzureRmAutomationModule cmdlet使用 Get-AzureRmAutomationModule cmdlet 检索模块时全局模块的模块版本不一致
【发布时间】：2019-01-11 02:04:49
【问题描述】：

我在尝试使用 Get-AzureRmAutomationModule cmdlet 从自动化帐户检索自动化模块时观察到以下行为。

当使用只有 2 个参数（ResourceGroupName 和 AutomationAccountName）的 cmdlet 时，模块列表将“global”模块的版本显示为空。但是，当通过传递 3 个参数（ResourceGroupName、AutomationAccountName 和模块名称）运行相同的 cmdlet 时，我们会获得全局模块的版本。

这是按设计的吗？如果是这样，为什么会这样？目前，门户网站还将全局模块的版本显示为空，而实际上它们已经有一个版本。下面列出了一些出现此行为的示例模块。

AuditPolicyDsc
PSDscResources
SecurityPolicyDsc
StateConfigCompositeResources
xDSCDomainjoin
xPowerShellExecutionPolicy
xRemoteDesktopAdmin

谢谢！

【问题讨论】：

标签： powershell azure-powershell azure-automation

【解决方案1】：

这里有一些个人意见供大家参考，我认为这可能是API的一个bug。

首先，我在门户中查看并测试了该命令，结果与您所说的一样，但该命令本质上是一个API。因此，我在 azure 资源浏览器中检查了我的自动化帐户（选择 AuditPolicyDsc 模块作为示例）。

检查所有模块：

只检查AuditPolicyDsc 模块：

你可以找到AuditPolicyDsc模块，不仅version，还有sizeInBytes和activityCount是不同的。

注意：另外，我认为它可能与global无关，你可以找到一个名为Microsoft.PowerShell.Core的模块，它是global > 但版本是not null。

他们使用了两个不同的API，我认为可能是他们造成的，否则可能不合理。

https://management.azure.com/subscriptions/{subscriptionid}/resourceGroups/{resourceGroup}/providers/Microsoft.Automation/automationAccounts/{automationAccount}/modules?api-version=2015-10-31

https://management.azure.com/subscriptions/{subscriptionid}/resourceGroups/{resourceGroup}/providers/Microsoft.Automation/automationAccounts/{automationAccount}/modules/AuditPolicyDsc?api-version=2015-10-31

如果您想改进它，我认为您可以在automation feedback 中发布想法，这可能会有所帮助。

【讨论】：

你好，乔伊。是的，我也相信这可能是一个错误。但是有两件事与你提到的有关，1）关于全局模块，我的意思是，这种行为我只在全局模块中看到，我同意，它并不适用于所有全局模块。 2）您提供的 2 个 URL，我相信第一个用于没有任何特定模块名称的通用 cmdlet，另一个用于特定模块名称；否则，它们几乎相同。
@AmoghNatu 是的，所以我认为这是一个错误，1）我知道你的意思，如果它是设计的，它将适用于所有全局模块，对吗？ 2）是的，我的意思是通用cmdlet和特定模块之间的错误，否则很难解释。
我在 github 上提出了这个问题，团队已经确认这是一个问题。更多更新尚未到来。 github.com/Azure/azure-powershell/issues/6846
@AmoghNatu 您可以标记它以供其他社区成员查找。
是的。我的错。我打算标记它，但只是发表评论并错过了。感谢您对答案的详细调查！