我们经常会发现 Azure 自动化 Runbook 失败并出现以下错误：
Get-AutomationPSCredential : The term 'Get-AutomationPSCredential' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:9
+ $cred = Get-AutomationPSCredential -Name SqlJobRunner
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-AutomationPSCredential:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
我们的不同运行手册似乎随机地出现此错误并失败。
Get-AutomationPSCredential是 Azure 提供的模块。这不是我们的代码，而是 Microsoft 的。
有时，它似乎只是“消失了”。
那么这里发生了什么？ Azure 自动化基础架构是否在不适合我们工作的时间重新加载或更新模块？我的印象是，一旦安排了运行手册，依赖模块就会“绑定”到运行手册，因此它们会在需要时出现。
为什么会发生这种情况？防止失败的最好方法是什么？
答案1
我接到了 Microsoft Azure 支持部门打来的电话，并了解到了根本原因。
我所在地区（美国东部）的 Azure Automation 运行的是 PowerShell 5.0。他们说 5.0 中存在一个问题，即模块是异步加载的。因此，不能保证跨模块依赖关系可用。
他们告诉我，当他们在 8 月份向美国东部地区发布 PowerShell 5.1 时，这个缺陷将会被修复。
他们提出了两项缓解措施：
- 在 try/catch 循环中执行 Get-AutomationPSCredential，在重试之间休眠 30 秒。
- 使用混合工作者将工作转移到安装了 PowerShell 5.1 的 VM。
另一个缓解方法是将所需模块导入到我需要的地方。这样做的一个复杂之处在于，有问题的函数 Get-AutomationPSCredential 来自本地开发中的程序集，而不是在自动化上下文中执行时。在使用 Azure 自动化创作工具包的本地开发中，该命令位于程序集中AzureAutomationAuthoringToolkit。在 Azure 中，它位于中Orchestrator.AssetManagement.Cmdlets。
我将尝试这样做：
Import-Module Orchestrator.AssetManagement.Cmdlets -ErrorAction SilentlyContinue
在 ISE 环境中执行时，该函数将一直存在，并且此 Import-Module 将默默失败。
答案2
按照你的描述，我们应该检查该模块是否有import，如果没有，就应该import。
我们可以使用门户来检查它：
自动化账户->模块->Orchestrator.AssetManagement.Cmdlet：
如果我们不导入它，我们应该使用门户来进口本模块：
