Get-AutomationPSCredential在Azure自动化中间歇性失败
每隔一段时间，我们都会发现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提供的模块。 这不是我们的代码，而是微软的。
有时，它似乎只是“走开”。
- Azure Linux帐户pipe理
- 站点到站点的VPN +互联网
- select多个networking安全组的安全规则（nsg）
- 如何在Azure中不同位置的两台虚拟机上运行客户端服务器程序？
- 更改Microsoft Azure帐户的Web界面语言
那么这里发生了什么？ Azure自动化基础架构是否在不适当的时候重新加载或更新模块？ 我曾经有过这样的印象：一旦运行手册安排好了，依赖模块就会与运行手册“绑定”，所以在需要的时候它们将会在那里。
为什么会发生这种情况，防止失败的最好办法是什么？
我收到了来自Microsoft Azure支持部门的电话，其根源在于此。
我的地区（美国东部）的Azure自动化在PowerShell 5.0上运行。 他们说5.0中有一个问题，那就是模块是asynchronous加载的。 因此，跨模块依赖关系不能保证可用。
他们告诉我，这个缺陷将在8月份向美国东部地区发布PowerShell 5.1时解决。
他们提供了两个缓解措施：
- 在try / catch循环中执行Get-AutomationPSCredential，在重试之间hibernate30秒。
- 使用混合工作器将工作转移到安装了PowerShell 5.1的虚拟机。
另一个缓解措施是在需要的地方导入所需的模块。 这样做的一个复杂情况是，所讨论的函数Get-AutomationPSCredential来自本地开发中的另一个程序集，而不是在Automation上下文中执行的程序集。 在使用Azure自动化创作工具包的本地开发中，该命令驻留在程序集AzureAutomationAuthoringToolkit 。 在Azure中，它位于Orchestrator.AssetManagement.Cmdlets 。
我要去试试这个： Import-Module Orchestrator.AssetManagement.Cmdlets -ErrorAction SilentlyContinue
在ISE环境中执行时，函数将始终存在，此导入模块将自动失败。
根据你的描述，我们应该检查模块是否有导入。 如果不是，我们应该导入它。
我们可以使用门户来检查它：
自动化帐户 – >模块 – > Orchestrator.AssetManagement.Cmdlets ： 
如果我们不导入它，我们应该使用门户导入这个模块：
