Enabling Multihoming on multiple clusters has clear benefits, but also underlies strict technical limitations. On this page we provide you with best practices to consider before deciding to roll out this feature.

Administrative Considerations

• MS-Teams provisioned services and their “MS Teams” Teams consist of users from the same region. As you provision other MS-Teams based services on another cluster, the same users will not be available there. 
• As a result we would recommend to do MS-Teams-based Service Provisioning only on one “home” cluster or take into consideration that provisioning MS-Teams based will potentially provision a larger set of users at once. Example: 
  • There is a pool of 5 users available
  • Cluster A has the first provisioned team and adds 3 users to Nimbus.
  • Cluster B can provision a team as well, but only the remaining 2 users can be used for the provisioning.
  • If no users would've available  (e.g. a Cluster C), an empty team would provisioned, that the tenant admin has to delete as no owner exists.
• Moving a user from one cluster to the other involves deletion on the source, so it can be re-added on the target cluster.
• Tenant / Partner Administrative groups can and should be split according to your needs so administrative efforts between clusters is distributed effectively. Vice versa the data access and conflicts of interest should be avoided by using multiple groups. 
• Organization Unit admins cannot partake in multiple clusters, as they require a (unique) Nimbus user.

Service Considerations

• Naming conventions for service UPN / PSTN numbers are necessary. Uniqueness is only detected when the Provisioning via Microsoft PowerShell is running. Across multiple clusters uniqueness is not checked before the script is running.
• Nimbus Power Automate Connector runs are cluster-agnostic, but can be copied over to be managed by a (different) user with similar access Power Automate Role privileges on the other cluster.

User Considerations

• Users can partake in multiple services, but only within those that were provisioned in their “home” cluster, as their Nimbus account cannot exist on other clusters simultaneously. 
• If a user needs to assist in multiple clusters, unique accounts with separate UPN are necessary. For this user, separate PSTN / Teams / Phone licenses need to be considered.
• Do a proper planning because there a certain cases that would require extensive additional work -> validation, synchronization (minimum) → See known limitations.