Installing Teams Connectors in multiple Azure regions

Large enterprises may want to install a Teams Connector in multiple regions to provide local capacity/resources.

As with your initial Teams Connector installation, you must follow the same guidelines when deploying additional Teams Connectors:

  • The Azure region for the new Teams Connector must support Automation and Fs series instance types. Ensure that you have sufficient resource quota and capacity for those instance types in that region.
  • Each Teams Connector that you deploy needs a unique DNS name and a certificate that matches that identity.
  • You may also be deploying a new pool of Conferencing Nodes to use with the new Teams Connector. These nodes would typically be in the same Azure region as the new Teams Connector, or in an on-premises datacenter in the same geographic area. You may want to use a different certificate (with a different pool name) for this set of Conferencing Nodes.

You do not need to create a new CVI app or perform any additional app authorizations when installing additional Teams Connectors — only one CVI app registration is required per tenant. However you do need to create a new API app for each new region, as described here.

Installing the additional Teams Connector application into Azure

As with the initial installation, you deploy additional Teams Connector applications through PowerShell ISE commands and scripts:

  1. Create a new variables initialization script for the new Azure region. You should do this by making a copy of your existing initialization script.

  2. Update the regional variables in the new initialization script with the values for your new Azure region. The variables you need to update are:

    • $PxVmssRegion: the short name that represents the new region in which you are deploying the new Teams Connector.
    • $PxTeamsConnFqdn: the hostname of the new Teams Connector.
    • $PxNodeFqdns: the pool name or names of the Conferencing Nodes that will communicate with the new Teams Connector.
    • $PxAzureLocation: the name of the Azure region into which you are deploying the new Teams Connector.
    • $PxPfxCertFileName: the filename of the PFX certificate file to upload to the new Teams Connector.
    • $PxNodesSourceAddressPrefixes: the IP addresses of the Conferencing Nodes that will communicate with the new Teams Connector instances.
    • $TeamsConnectorApiApplicationId: this must be updated to hold the ID of a new Teams Connector API app for this region, and is described later in the process below.

  3. Create the static and dynamic resource groups for the new region and ensure that the person performing the installation has the Owner role for them. (You do not need to create a resource group for the Azure Bot.)

    These steps must be performed by the Owner of the Azure subscription used for the Teams Connector.

    1. Run the following PowerShell command to connect to Azure:

      • In all standard deployments run:

        Connect-AzAccount

      • If this is a GCC High / Azure US Government Cloud deployment then use this command instead:

        Connect-AzAccount -EnvironmentName AzureUSGovernment

      Then follow the prompts to sign in to Azure.

    2. Run the variable initialization script (to set the required subscription, resource group name and region variables).

    3. Ensure that you are using the Azure subscription for the Teams Connector:

      Set-AzContext -SubscriptionId $PxSubscriptionId

    4. Run the following script to create the resource groups for static and dynamic resources:

      Copy to clipboard 
      # Resource group for static resources for the Teams Connector / region
      New-AzResourceGroup -Name $PxTeamsConnStaticResourceGroupName -Location $PxAzureLocation -Force -Tag $tags

      # Resource group for the Teams Connector VMSS (per region)
      New-AzResourceGroup -Name $PxTeamsConnResourceGroupName -Location $PxAzureLocation -Tag $tags

    5. Ensure that the person who will perform all of the remaining installation steps has the Azure Owner role for the static and dynamic resource groups you have just created. If the Owner of the Azure subscription will perform all of the remaining installation steps then you can skip to Create the Teams Connector API app. below.

      Otherwise, you must run the following commands to assign the required roles for the resource groups you have just created to the person who will perform all of the remaining installation steps:

      New-AzRoleAssignment -SignInName <email_name> -RoleDefinitionName "Owner" -ResourceGroupName $PxTeamsConnStaticResourceGroupName

      New-AzRoleAssignment -SignInName <email_name> -RoleDefinitionName "Owner" -ResourceGroupName $PxTeamsConnResourceGroupName

      where <email_name> is the email address / user principal name of the person who will perform the remaining steps; for example where alice@example.com will perform the upgrade/redeploy, the SignInName would be -SignInName alice@example.com for the commands listed above.

    Note:

    • Some of these resource groups only need creating once; others need recreating when you upgrade or if you redeploy:

      • The static resource group ($PxTeamsConnStaticResourceGroupName) only has to be created when deploying in a region for the first time — you do not have to repeat this when redeploying or for subsequent upgrades.
      • The dynamic resource group ($PxTeamsConnResourceGroupName) has to be recreated in each region whenever you upgrade or redeploy.
    • In the future, if another person were to upgrade or redeploy the Teams Connector, that person would also have to be granted the appropriate roles for these resource groups.
    • You can also use the Azure portal to check/assign permissions by selecting the resource group and using the Access control (IAM) option.

  4. Create the Teams Connector API app.

    You must create in this region an Azure app that is used to secure requests to the Teams Connector APIs.

    Each region must have its own Teams Connector API app, and thus the variables initialization script for each region must be updated to contain the API App ID for that region.

    1. Run the following PowerShell command to connect to Azure:

      • In all standard deployments run:

        Connect-AzAccount

      • If this is a GCC High / Azure US Government Cloud deployment then use this command instead:

        Connect-AzAccount -EnvironmentName AzureUSGovernment

      Then follow the prompts to sign in to Azure.

    2. Change directory to the folder into which you extracted the files from the Teams Connector ZIP.

    3. Run the following PowerShell commands to connect to Microsoft Graph:

      Copy to clipboard 
      # Set execution policy for the current PowerShell process, when prompted type A (Yes to All)
      Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

      # The Unblock-File cmdlet lets you run PowerShell script files that were downloaded from the internet. 
      # By default, these files are blocked to protect the computer from untrusted files.
      Get-ChildItem -Recurse | Unblock-File

      # Import the PexTeamsCviApplication PowerShell module
      Import-Module .\PexTeamsCviApplication.psm1

      # Connect to Graph
      Connect-PexTeamsMsGraph
    4. Run your variable initialization script to set the required prefix and region name variables.

    5. Run the following command to create the Teams Connector API app.

      Copy to clipboard 
      $teamsConnectorApiApp = New-MgApplication -DisplayName "${PxBaseConnName}-TeamsConn-${PxVmssRegion} Pexip Teams Connector API" -SignInAudience "AzureADMyOrg"

      Please allow one minute for this command to complete and propagate within Azure.

    6. Run the following commands to obtain the Teams Connector API app ID.

      Note that if the New-MgServicePrincipal command fails, this means that you have not waited long enough for the previous command to complete.

      Copy to clipboard 
      $teamsConnectorApiSp = New-MgServicePrincipal -AppId $teamsConnectorApiApp.AppId -Tags {WindowsAzureActiveDirectoryIntegratedApp}
      $TeamsConnectorApiApplicationId = $teamsConnectorApiApp.AppId

      Write-Host
      Write-Host
      Write-Host "`n----------------------------------------`n"
      Write-Host
      Write-Host "### Teams Connector API App ID MUST be saved in the variables initialization script ###"
      Write-Host
      Write-Host "`$TeamsConnectorApiApplicationId = `"$($TeamsConnectorApiApplicationId)`""
      Write-Host
      Write-Host "`n----------------------------------------`n"
      Write-Host
      Write-Host

    7. When the command runs, it generates some output that lists the Teams Connector API App ID, similar to this:

    8. Copy the output line that defines the API App ID and paste it into the variable initialization script, replacing the existing variable definition in the script that currently contains the API App ID for the main region used by the original variables script (the one you used as the basis for the variables script for this new region).

      i.e. the script will initially contain:

      $TeamsConnectorApiApplicationId = "<App ID for the existing main region>"

      and it needs changing to the App ID created in step 2:

      $TeamsConnectorApiApplicationId = "<App ID for the new region>"

      (If you will be performing the rest of the deployment, in the same PowerShell session, there is no need to re-run the variable initialization script as the new $TeamsConnectorApiApplicationId variable has been set in the previous steps.)

    9. If somebody else will be completing the deployment, ensure that the person who will perform all of the remaining installation steps has Owner permissions for the API app. See Assigning Owner permissions for the API app for more information.

    Note that:

    • This app does not have to be granted any permissions. It does not have access to any resources in the Microsoft Entra ID tenant. It has no associated credentials.

  5. Run the redeploy script to install the Teams Connector into the new region.

    This should be the script that you produced after the initial installation or most recent upgrade. This script should already have the variables for the CVI App ID and password updated with the correct values for your deployment. As with the initial installation, we recommend running each group of commands step-by-step within PowerShell.

  6. Update DNS with the new Teams Connector's name and IP address.

Note that you do not need to create a new CVI app or perform any additional app authorizations when installing additional Teams Connectors.

Pexip Management Node configuration

To configure Pexip Infinity to use the new Teams Connector:

  1. If required, set up new Conferencing Nodes / locations that will use the new Teams Connector.
  2. Ensure that the Conferencing Nodes have suitable certificates installed (see Certificate and DNS examples for a Microsoft Teams integration).
  3. Configure a new Microsoft Teams Connector (Call control > Microsoft Teams Connectors) where the address of the Teams Connector is the name specified in $PxTeamsConnFqdn in your new initialization script for the new Azure region.
  4. Assign the new Teams Connector to the locations (and thus Conferencing Nodes) where you want that new Teams Connector to be used (Platform > Locations).

  5. Now that you have multiple Teams Connectors you must ensure that calls are routed via your desired Conferencing Nodes to the appropriate Teams Connector. This assumes that GeoDNS or your call control system is routing incoming calls to the appropriate Conferencing Nodes / locations.

    • When you have just one Teams Connector, all of the Call Routing Rules handling calls to Microsoft Teams are typically all configured with an Outgoing location set to the one location containing your Conferencing Nodes that communicate with your Teams Connector.
    • When you have two (or more) Teams Connectors, you will also have two (or more) locations, where each location typically contains the Conferencing Nodes that are local to each Teams Connector.

    To ensure that your calls are routed via the most appropriate Conferencing Nodes and Teams Connectors, you must modify your existing Call Routing Rules and also create some new rules. Typically the best way to do this is to use the Calls being handled in location setting on each rule, so that you can route calls via the appropriate Teams Connector based on where the incoming call was originally received.

    For example, if you previously only had a single location (called "Europe-DMZ") containing all of your Conferencing Nodes and that location was also configured as the Outgoing location on all of your rules, then all calls would have been received in — and routed out of — those nodes to your single Teams Connector (also most likely deployed in a European Azure region).

    Let's assume that you now add a second location (called "USA-DMZ") containing new Conferencing Nodes and you want to route calls local to America to a new Teams Connector that is deployed in an American region, and keep your other calls routed via the Europe nodes and Europe Teams Connector. You now need to have another set of Call Routing Rules that are based on (i.e. copies of) your existing rules but where you:

    • keep the same rule settings for protocols, alias regexes and trust settings across each pair of rules
    • assign a Priority value for each new rule that keeps it next to the rule it was based upon

    • specify the Calls being handled in location and Outgoing location fields as appropriate for each pair of rules, meaning that:

      • your original rule now has Calls being handled in location = "Europe-DMZ" and Outgoing location = "Europe-DMZ"
      • your new rule has Calls being handled in location = "USA-DMZ" and Outgoing location = "USA-DMZ"

      Note that if you have many locations, you can specify some higher priority rules (lower numbers) with a specific location defined in Calls being handled in location, and have a lower priority rule with Calls being handled in location set to Any location to handle any calls that were not caught by the previous location-specific rules.

    This means that Incoming calls will be routed via the Teams Connector that is local to the Conferencing Nodes that received the call.

This example diagram shows how your Call Routing Rules should evolve when moving from routing all calls via a single Teams Connector to deploying a second Teams Connector in another Azure region. Note that this example also includes locations/nodes in the enterprise internal network, in addition to the locations/nodes in the DMZ.

Routing rules for one Teams Connector compared to two Teams Connectors

You do not have to change your existing Virtual Reception configuration — there is minimal performance overhead by always using a single location and Teams Connector to resolve Teams Conference IDs entered into a Virtual Reception.