AzureRmADAppCredential的EndDate日期格式问题求助

我之前在部署Azure自动化账户的服务主体时也踩过这个坑，给你几个实际有效的排查和解决方向：

• 先检查有效期的硬性限制：Azure AD对服务主体凭据的有效期有严格要求，不能超过当前日期往后推2年，而且绝对不能早于当前时间。很多人会不小心设置成3年甚至更久，直接触发这个错误，先确认你的EndDate是不是在合法范围内。

• 用DateTime对象代替字符串日期：别再纠结各种字符串格式了，直接生成PowerShell能识别的DateTime对象，彻底避免解析错误。比如：

  # 设置为当前时间+2年（Azure允许的最大有效期）
  $validEndDate = (Get-Date).AddYears(2)
  New-AzureRmADAppCredential -ApplicationId $yourAppId -EndDate $validEndDate
  

• 升级AzureRm模块（或迁移到Az模块）：老版本的AzureRm模块确实存在EndDate参数的处理bug，尤其是低于6.13.1的版本。建议直接升级到最新版：

  Update-Module -Name AzureRm -Force
  

  另外，AzureRm已经被官方弃用了，长远来看更建议迁移到Az模块，用New-AzADAppCredential命令，它的参数逻辑更稳定，很少出现这类日期问题。

• 规避时区差异问题：如果你的本地系统时区和UTC不一致，可能导致日期被解析成过去的时间。强制使用UTC时间来生成EndDate：

  $utcEndDate = (Get-Date).ToUniversalTime().AddYears(2)
  New-AzureRmADAppCredential -ApplicationId $yourAppId -EndDate $utcEndDate
  

• 尝试不指定EndDate：如果你的业务场景允许，完全可以省略EndDate参数，命令会自动设置一个默认的1年有效期，这样能直接绕开日期相关的所有问题，快速验证是否是日期参数导致的错误。

内容的提问来源于stack exchange，提问作者Dave C