使用Bicep部署含Email服务和托管域的Azure通信服务报错

我使用Bicep部署Azure通信服务（Communication Service），并尝试将其与带有Azure托管域的邮件服务（Email Service）关联。脚本能够成功创建所有资源，但在关联通信服务与域时抛出错误："The specified domain is unable to be linked."。奇怪的是，该域在通信服务的控制台界面中显示已正确关联。我曾尝试使用2023-04-01-preview API版本，但因无法将location设置为global而失败。完整Bicep代码如下：

var communicationServiceName = 'cs-medienstudio-dev'
var emailServiceName = 'es-medienstudio-dev'

resource emailService 'Microsoft.Communication/emailServices@2023-03-31' = {
  name: emailServiceName
  location: 'global'
  properties: {
    dataLocation: 'Europe'
  }
}

resource emailServiceDomain 'Microsoft.Communication/emailServices/domains@2023-03-31' = {
  parent: emailService
  name: 'AzureManagedDomain'
  location: 'global'
  properties: {
    domainManagement: 'AzureManaged'
  }
}

resource senderUserName 'Microsoft.Communication/emailServices/domains/senderUsernames@2023-03-31' = {
  parent: emailServiceDomain
  name: 'donotreply'
  properties:{
    username: 'DoNotReply'
    displayName: 'DoNotReply'
  }
}

resource communcationService 'Microsoft.Communication/communicationServices@2023-03-31' = {
  name: communicationServiceName
  location: 'global'
  properties: {
    dataLocation: 'Germany'
    linkedDomains: [
      emailServiceDomain.id
    ]
  }
}

1. 显式添加跨资源依赖 #

虽然Bicep会自动处理父资源的依赖关系，但跨资源类型的关联可能存在时序问题——通信服务尝试关联域时，域的初始化可能尚未完成。可以通过显式依赖域的子资源（发件人用户名），确保域完全就绪后再执行关联操作：

修改后的通信服务资源定义：

resource communcationService 'Microsoft.Communication/communicationServices@2023-03-31' = {
  name: communicationServiceName
  location: 'global'
  dependsOn: [senderUserName] // 等待域的子资源创建完成，确保域初始化完毕
  properties: {
    dataLocation: 'Germany'
    linkedDomains: [
      emailServiceDomain.id
    ]
  }
}

2. 升级API版本至稳定版 #

2023-03-31版本的API在域关联逻辑上存在已知的时序问题，建议升级到2023-09-01或更新的稳定版API，这些版本不仅修复了关联报错问题，还对global location的支持更完善：

将所有资源的API版本统一替换为2023-09-01，示例如下：

resource emailService 'Microsoft.Communication/emailServices@2023-09-01' = {
  name: emailServiceName
  location: 'global'
  properties: {
    dataLocation: 'Europe'
  }
}

resource emailServiceDomain 'Microsoft.Communication/emailServices/domains@2023-09-01' = {
  parent: emailService
  name: 'AzureManagedDomain'
  location: 'global'
  properties: {
    domainManagement: 'AzureManaged'
  }
}

// 其余资源的API版本同步修改为2023-09-01

3. 统一数据区域配置 #

通信服务的dataLocation设置为Germany，而邮件服务的dataLocation为Europe，跨区域配置可能导致资源同步延迟。尝试将两者的dataLocation统一为Germany，减少隐性的同步问题：

修改邮件服务的dataLocation：

resource emailService 'Microsoft.Communication/emailServices@2023-09-01' = {
  name: emailServiceName
  location: 'global'
  properties: {
    dataLocation: 'Germany' // 与通信服务的数据区域保持一致
  }
}

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