Office 365通过Google SAML配置SSO及用户自动预配时遇到联合域设置失败问题

我之前帮不少用户处理过类似的Office365联合身份配置问题，看到你遇到的这些报错确实挺闹心的，给你梳理几个针对性的排查方向和解决方案：

一、先解决「域名已在其他Office365服务中使用」的核心问题 #

你运行Confirm-MsolDomain时遇到的报错：

Confirm-MsolDomain : Unable to verify this domain because it is used elsewhere in Office 365. Remove the verified domain from the other service before adding it here.

这个是关键线索，说明你的ourDomain.com域名已经被关联到另一个Office365/Azure AD租户了——哪怕那个租户可能已经被注销，残留的记录也会导致当前租户无法修改域名的身份验证类型。

可以试试这些操作：

• 用全局管理员账号运行PowerShell命令，查询域名关联的租户信息：

  Get-MsolPartnerContract -DomainName ourDomain.com
  

  如果返回了其他租户的信息，你需要先登录到那个租户，把ourDomain.com域名删除（注意提前转移该域名下的用户资源），之后再回到当前租户操作。
• 如果没有返回结果，说明可能是Microsoft后台的残留记录，这时候你提交的Microsoft工单就很关键了，把这个报错和你尝试过的操作详细反馈给支持人员，让他们帮忙在后台排查域名的关联状态。

二、处理「内部服务错误」的可能方案 #

你切换默认域到ourDomain.onmicrosoft.com后，运行Set-MsolDomainAuthentication还是报错内部服务异常，试试这些办法：

• 更新MSOnline模块：本地PowerShell的模块版本过旧可能导致兼容性问题，先更新到最新版本：

  Install-Module MSOnline -Force -AllowClobber
  

  之后重新运行Connect-MsolService登录，再执行设置命令。
• 换个PowerShell环境：试试用Azure Cloud Shell（登录Azure门户后打开在线Shell）来执行命令，避免本地网络或者环境配置的干扰。
• 延长等待时间：虽然你已经等了12小时，但租户配置的跨区域同步有时候需要24小时以上，尤其是切换默认域这种操作，再耐心等一段时间后重试。

三、额外的排查注意点 #

• 确认你的全局管理员账号没有权限限制：比如是否开启了安全默认值，是否需要完成MFA验证，或者账号有没有被设置了操作限制。
• 检查域名的DNS记录：确保之前用于验证的TXT/MX记录没有被修改，虽然域名已经显示Verified，但DNS异常可能导致租户的身份验证配置流程卡住。

希望这些方向能帮你解决问题，也可以把排查的结果同步给Microsoft支持，加快工单的处理进度。

备注：内容来源于stack exchange，提问作者Sean