Maintaining your Teams Connector deployment

After you have installed and configured your Teams Connector there are several maintenance tasks you may need to perform, such as adding extra Conferencing Nodes, changing your call capacity or upgrading the platform to the latest software version.

Modifying the Teams Connector's configuration

If you need to change the configuration on the Teams Connector after it has been deployed, you must make the necessary changes to the variables in your initialization script and then redeploy it using the new configuration, as described below. Configuration changes that require redeployment include:

  • Changing the Teams Connector's certificate
  • Changing the pool name or node FQDNs of the associated Conferencing Nodes (the name referenced by the $PxNodeFqdns variable in the initialization script)

Note that you do not need to redeploy the Teams Connector if you need to change the Azure Network Security Group configuration, for example to add the IP address of a new Conferencing Node, or if you need to modify the number of Teams Connector instances.

Upgrading the Teams Connector to the latest software

In version 20 and 21 of the Teams Connector, Pexip used a trusted app and a guest app to connect participants to Teams meetings. In version 22, only the trusted app is required, which now performs both the trusted and guest joining workflows. When upgrading your Teams Connector to version 22, you must use the latest deployment scripts as contained within this documentation and as described below.

To upgrade your Teams Connector:

  1. You can continue to use the trusted app from your existing deployment — this is now just referred to as the Pexip CVI app. The guest app is no longer used and can be deleted after you have completed your upgrade. You do not need to delete and then recreate your trusted app. Also, you do not need to modify your Call Routing Rules in Pexip Infinity.
  2. You can continue to use the variables initialization script that you used in version 21. If you are upgrading from version 20 then you need to add the following variables to the saved version of your variables script: $PxConsentSourceAddressPrefixes, $PxWupdScheduledInstallDay, $PxWupdScheduledInstallTime, $PxWupdActiveHoursStart, $PxWupdActiveHoursEnd and $PxCustomerUsageAttribution (see Specify installation variables used in the PowerShell commands for more information on the settings for these variables).
  3. You must use the latest version of the redeploy script as listed further down this page. The version you saved from v20/v21 will not work.

    After copying the new redeploy script, update the two lines in the redeploy script that say:

    $AppId = ""
    $AppPassword = ""

    to contain the ID and password of the trusted app from the version of the redeploy script you saved from v20/v21 for your existing deployment.

  4. You can now complete the upgrade by following the standard redeploy process with your existing trusted app and your new redeploy script.
  5. For completeness, when the upgrade is complete, you can delete the guest app from Azure:

    1. Within the Azure portal, select Azure Active Directory.
    2. Under Manage, select App registrations.
    3. Select the guest app registration with the prefix of the Teams Connector you have upgraded, and then Delete it.
    4. Go to Resource groups within the portal.
    5. Select the <prefix>-TeamsBotChan-RG resource group for your Teams Connector, and within that resource group select the Bot Channels Registration called <prefix>-Guest-TeamsBot and then Delete it.

If you have deployed multiple Teams Connectors, follow the same redeploy process (with the new redeploy script) for each Teams Connector.

Redeploying the Teams Connector

The Teams Connector redeployment process described below is required when you want to:

  • upgrade the Teams Connector software
  • change the Teams Connector's configuration (such as its certificate, or the names of the associated Conferencing Nodes)
  • deploy a new Teams Connector in a different Azure region.

Note that there is no need to backup the Teams Connector as there are no specific settings, status or history information to preserve — if the deployment is lost you can just reinstall it with this redeploy process.

There are three main steps to redeploying the Teams Connector:

  1. Check that you have the latest relevant version of the Teams Connector software, and your original initialization and redeploy scripts.
  2. Remove some of the existing Teams Connector resources from Azure.
  3. Reinstall the Teams Connector software.

Before running your scripts we recommend that you check the Azure status (https://status.azure.com) for your region. Any ongoing issues in your region with the Azure services used by the Teams Connector could cause the script to fail.

The redeployment steps are shown in the following diagram and are then described in detail below.

Deployment script flowchart

Check Teams Connector software and retrieve your original scripts

  1. Download the latest relevant version of the Teams Connector ZIP file (Pexip_Infinity_Connector_For_Microsoft_Teams_v22_<build>.zip) from the Pexip support site.

    Ensure that the Teams Connector version you download is the same version as your Pexip Infinity deployment.

  2. Extract the files to a folder on your administrator PC.
  3. Add your PFX certificate for the Teams Connector to this folder.
  4. Retrieve your saved copies of the initialization and redeploy scripts. You should have created and stored your version of these scripts after you completed your initial installation of your first Teams Connector.

  5. Check your saved copy of the initialization script that sets the environmental variables:

    • If you are redeploying and need to change any of the previous configuration you should also adjust your initialization script as required.
    • If you have Teams Connectors in many regions, ensure that have the correct versions of the initialization scripts that set the regional variables to the appropriate values.
  6. Check your saved copy of the redeploy script:

    • If you are upgrading to v22, ensure that you first follow the instructions at Upgrading the Teams Connector to the latest software above to get the latest script and set the App ID correctly.
    • Confirm that you have updated the redeploy script with your Pexip App ID and credentials:

      • When the installation script ran, it generated some output that listed the App ID and credentials, similar to this:

      • These output lines should have been used to replace the two existing lines in the redeploy script that say:

        $AppId = ""
        $AppPassword = ""

        This means that when you run the redeploy script, you will reuse the app and password that you created the first time.

    • If you are upgrading to v22 and you need to maintain access to the Admin Consent web page (typically only necessary if you are a service provider), then after completing the commands in the redeploy script you should also run the following additional PowerShell commands to reinstate the Admin Consent web page:

      Import-Module .\PexTeamsCviApplication.psm1

      $BotChanResourceGroupName = "$($PxBaseConnName)-TeamsBotChan-RG"

      $AdminConsentUrl = Publish-PexTeamsAdminConsentWebSite -SubscriptionId $PxSubscriptionId -ResourceGroupName $BotChanResourceGroupName -PxBaseConnName $PxBaseConnName -AppId $AppId -SourceAddressPrefixes $PxConsentSourceAddressPrefixes -Confirm:$false

      and then

      Write-Host "To give consent to the app, go to: $AdminConsentUrl"

      Note that if you run the above commands in a new window/session you will first need to run the PowerShell variables initialization script.

    • You should use this redeploy script in all scenarios except for when deploying a Teams Connector for the very first time for your Azure subscription i.e. you should use this script when upgrading, redeploying, or deploying a new Teams Connector in another region.
    • You only need one version of this script — you can use the same redeploy script in every region if you have multiple Teams Connectors.

Remove some Teams Connector resources from Azure

Before redeploying or upgrading a Teams Connector, you must remove some of the existing Teams Connector resources from Azure:

  1. Identify all of your existing Teams Connector resources in Azure: in the Azure portal, for your subscription, go to Resource groups and search for the prefix that you used when naming your resources — this is the value of the $PxBaseConnName variable in the initialization script.

    You will see resource groups with names in the following formats:

    • <prefix>-TeamsBotChan-RG: this contains the Bot channel registrations and must not be deleted.
    • <prefix>-TeamsConn-<region>-RG: this contains the Teams Connector instances (Virtual Machine scale set) and is to be deleted in the next step.
    • <prefix>-TeamsConn-<region>-static-RG: this contains the public IP address of the Teams Connector and must not be deleted.

    If you have deployed a Teams Connector in multiple regions you will see several <prefix>-TeamsConn-... resource groups.

  2. Select the <prefix>-TeamsConn-<region>-RG resource group.

    (Do not select any resource groups with TeamsBotChan or Static in its name.)

    If you have many Teams Connectors in multiple regions, select the resource group with the <region> name you want to delete.

  3. Select Delete resource group and confirm with the name of the resource group.

    Your Teams Connector will stop working when you confirm this step.

  4. The deletion may take a few minutes to complete. When the resource group is deleted you can start to redeploy the Teams Connector as described below.

Redeploy the Teams Connector

To redeploy the Teams Connector:

  1. In PowerShell, run your initialization script that sets the environmental variables.

    If you have Teams Connectors in many regions, ensure that you run the version of the initialization script that sets the regional variables to the appropriate values.

  2. In PowerShell run your redeploy script.

    You only need one version of this script — you can use the same script in every region if you have multiple Teams Connectors.

This is the redeploy script. It is a variation on the installation script that only performs the necessary commands to redeploy the Teams Connector. As with the initial installation, we recommend running each group of commands step-by-step within PowerShell.

# Connect to PowerShell AzureRm
# Set execution policy for the current PowerShell process Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process # Connect to Azure Resource Manager PowerShell (in same window to reuse variables) Import-Module AzureRM -MinimumVersion 6.0.0 Connect-AzureRmAccount # Azure RM commands
# Before running the following commands, update the following 2 lines/variables with the App ID and password # that were output when the installation script was run $AppId = "" $AppPassword = "" # Change context to the Pexip Subscription and set the app credentials Set-AzureRmContext -SubscriptionId $PxSubscriptionId $AppSecurePassword = ConvertTo-SecureString -AsPlainText $AppPassword -Force $AppCred = New-Object System.Management.Automation.PSCredential -ArgumentList $AppId,$AppSecurePassword # Virtual Machine Scale Set (VMSS) creation # Provide credentials to be used as local user/password for Pexip Teams Connector VMs # Create a password (using the variables above) for the Windows VM $PxWinAdminSecurePassword = ConvertTo-SecureString -AsPlainText $PxWinAdminPassword -Force $PxWinAdminCred = New-Object System.Management.Automation.PSCredential -ArgumentList $PxWinAdminUser,$PxWinAdminSecurePassword # Optionally if you do not prefer to have a password set as a variable, use Get-Credential # $PxWinAdminCred = Get-Credential # Create Resource group for Teams Connector Load Balancer (per region) # This stores the public IP address of the Teams Connector Load Balancer # so that the address can be re-used on upgrade or redeploy # this command can be skipped when redeploying - it's only required when deploying in a new region for the first time New-AzureRmResourceGroup -Location $PxAzureLocation -ResourceGroupName $PxTeamsConnStaticResourceGroupName -Force # Create Resource group for Teams Connector VMSS (per region)
# This section of the script is region specific, ensure that the initial variables # are set with the correct values for $PxAzureLocation, $PxTeamsConnFqdn and $PxVmssRegion
New-AzureRmResourceGroup -Location $PxAzureLocation -ResourceGroupName $PxTeamsConnResourceGroupName # Deploy the Teams Connector VMs # this step can take up to 30 minutes to complete .\create_vmss_deployment.ps1 -SubscriptionId $PxSubscriptionId -ResourceGroupName $PxTeamsConnResourceGroupName -VmssName "$($PxBaseConnName)$($PxVmssRegion)" -VMAdminCredential $PxWinAdminCred -PfxPath $PxPfxCertFileName -TeamsConnectorFqdn $PxTeamsConnFqdn -PexipFqdns $PxNodeFqdns -instanceCount $PxTeamsConnInstanceCount -AppCredential $AppCred -StaticResourcesResourceGroupName $PxTeamsConnStaticResourceGroupName -PublicIPAddressResourceName "$($PxBaseConnName)-TeamsConn-$($PxVmssRegion)-PIP" -IncidentReporting $PxTeamsConnIncidentReporting -Encryption $PxTeamsConnDiskEncryption -RdpSourceAddressPrefixes $PxMgmtSrcAddrPrefixes -PexipSourceAddressPrefixes $PxNodesSourceAddressPrefixes -WupdScheduledInstallDay $PxWupdScheduledInstallDay -WupdScheduledInstallTime $PxWupdScheduledInstallTime -WupdActiveHoursStart $PxWupdActiveHoursStart -WupdActiveHoursEnd $PxWupdActiveHoursEnd -CustomerUsageAttribution $PxCustomerUsageAttribution # supply the PFX certificate file password when prompted # Please enter the password for the PFX certificate '.\xxxxxxxx.pfx': *************** # Generating the next steps summary (this assumes you are connected to AzureRM) # # Setting subscription Set-AzureRmContext -SubscriptionId $PxSubscriptionId # Getting Network Security Group Resource ID $nsgResId = (Get-AzureRmResource -ResourceGroupName $PxTeamsConnResourceGroupName -ResourceType Microsoft.Network/networkSecurityGroups).ResourceId # Getting Public IP details $publicIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $PxTeamsConnStaticResourceGroupName).IpAddress $publicIpFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $PxTeamsConnStaticResourceGroupName).DnsSettings.Fqdn # Printing next steps Write-Host Write-Host Write-Host "`n--------------------------`n" Write-Host Write-Host "When the Teams Connector is deployed, you have to create a DNS CNAME from your official hostname" Write-Host Write-Host "1) Setup a DNS CNAME for $($PxTeamsConnFqdn) pointing to " Write-Host " $($publicIpFqdn)" Write-Host Write-Host " When this is done, and you can confirm a DNS lookup of $($PxTeamsConnFqdn) resolves to" Write-Host " your Public IP of the load balancer ($($publicIpAddress)) - you are ready to proceed." Write-Host Write-Host "`n--------------------------`n" Write-Host Write-Host
Copied!

Adding or removing Conferencing Nodes

You can change the pool of Conferencing Nodes that communicates with the Teams Connector without having to redeploy the Teams Connector itself, providing that the certificate installed on any new Conferencing Nodes contains an identity that was in the $PxNodeFqdns initialization script variable when the Teams Connector was originally deployed.

For example, if you have a Teams Connector deployed as shown in Certificate and DNS examples for a Microsoft Teams integration i.e.

  • two existing Conferencing Nodes called px01.vc.example.com and px02.vc.example.com
  • both nodes have the same certificate installed with subject name px.vc.example.com, and altNames px.vc.example.com, px01.vc.example.com and px02.vc.example.com
  • the Teams Connector was deployed with the $PxNodeFqdns variable set to px.vc.example.com

and you want to add a new Conferencing Node px03.vc.example.com, you would have to:

  1. Install a certificate on the new Conferencing Node that contains the common px.vc.example.com identity.

    To remain consistent with our example certificate naming policy this would mean creating a new certificate with a subject name of px.vc.example.com and altNames of px.vc.example.com, px01.vc.example.com, px02.vc.example.com and px03.vc.example.com. You would then install this certificate on the new node and the two existing nodes.

    Note that purely from a Teams Connector perspective, the node certificate only needs to contain the identity specified in the $PxNodeFqdns variable, but if the same Conferencing Nodes handle SIP and Skype for Business / Lync signaling then the example certificate naming policy used here is more appropriate.

  2. You may need to update the Network Security Group associated with your Teams Connector in Azure.

    The "MCU-signalling-endpoint" rule (priority 120) specifies the IP addresses of the Conferencing Nodes that can communicate with the Teams Connector. These addresses were based on the value of the $PxNodesSourceAddressPrefixes initialization script variable. If individual IP addresses were specified then you need to add the IP address of the new Conferencing Node to this NSG rule. If the variable specified an IP subnet and the new node's address is within that subnet, then no changes are required.

  3. If you had to update the NSG rule, you should add the same new address to the $PxNodesSourceAddressPrefixes variable in your stored initialization script to keep it in sync with your actual deployment in case it is needed for a future redeployment or upgrade.

Removing Conferencing Nodes

If you need to remove a Conferencing Node from the pool for any reason, you do not need to make any immediate changes to your Teams Connector / Azure configuration. However, you should make any necessary changes to the $PxNodesSourceAddressPrefixes variable in your stored initialization script to keep it in sync with your actual deployment.

Changing the alternative dialing instructions or IVR address

You can use the Set-CsVideoInteropServiceProvider command to change the alternative dialing instructions or the IVR address (TenantKey).

Changing the alternative dialing instructions

You can update the webpage of "Alternate VTC dialing instructions" that the recipient of the meeting invite can look at, by adding or removing some of the address types that are displayed.

You do this by using the Set-CsVideoInteropServiceProvider command and supplying a new InstructionUri parameter, following the same rules as described when you first created the service provider.

In our original example, the service provider was created with the command:

New-CsVideoInteropServiceProvider -Name Pexip -TenantKey "teams@example.com" -InstructionUri "https://px.vc.example.com/teams/?conf={ConfId}&ivr=teams&d=example.com&ip=198.51.100.40&test=test_call&w" -AllowAppGuestJoinsAsAuthenticated $true -AadApplicationIds "c054d1cb-7961-48e1-b004-389e81356232"

To change the instructions to remove the "Test call" option, for example, the revised InstructionUri parameter would be "https://px.vc.example.com/teams/?conf={ConfId}&ivr=teams&d=example.com&ip=198.51.100.40&w"

and the command to apply the revised InstructionUri parameter would be:

Set-CsVideoInteropServiceProvider -Identity Pexip -InstructionUri "https://px.vc.example.com/teams/?conf={ConfId}&ivr=teams&d=example.com&ip=198.51.100.40&w"

Changing the IVR address (TenantKey)

The IVR address (TenantKey) is the alias that you assign to the Pexip Virtual Reception that is to act as the IVR gateway into the Teams meetings. In our original example this was set to teams@example.com.

To change the address you can use the Set-CsVideoInteropServiceProvider command and supply a new TenantKey parameter, for example:

set-CsVideoInteropServiceProvider -Identity Pexip -TenantKey "newaddress@example.com"

Note that when using Set-CsVideoInteropServiceProvider, the first parameter is called -Identity, not -Name.

These changes may take up to 6 hours to come into effect.

Changing the call capacity of a Teams Connector

When you install a Teams Connector application in Azure, you initially specify the number of Teams Connector instances (VMs) to deploy.

You can subsequently modify the number of instances via the Azure portal, to reflect changing capacity requirements.

To change the number of instances:

  1. In the Azure portal, for your subscription, go to the Virtual machine scale set in your Teams Connector resource group.
  2. In the Settings menu, select Scaling.
  3. Use the slider in the Configure tab to increase/decrease the instance count as appropriate.

    Note that if you reduce the instance count, any calls that are being handled by an instance that Azure chooses to delete will be dropped.

Adding extra Teams Connectors in other 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-prem 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.

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.
  3. Run the new initialization script for your new Azure region.
  4. Run the redeploy script that you produced after the initial installation. This script should already have the variables for the 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.

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

Note that you do not need to create any new apps 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 meeting codes entered into a Virtual Reception.

Changing management workstation access

When you deploy a Teams Connector, a Network Security Group (NSG) is created within Azure. The NSG includes an "RDP" rule (priority 1000) that controls RDP access to the Teams Connector instances from any addresses specified in the $PxMgmtSrcAddrPrefixes installation variable. If no addresses were specified then a Deny rule is created instead.

You can change or enable this rule if you want to specify a different set of management workstation addresses. To do this:

  1. In the Azure portal, for your subscription, go to the Network security group in your Teams Connector resource group.
  2. Select rule 1000 RDP.
  3. Change the Source IP addresses/CIDR ranges as appropriate for the management workstation / network subnet addresses you want to allow RDP access.
  4. Set Action to Allow or Deny as appropriate.
  5. Select Save.
  6. Update the $PxMgmtSrcAddrPrefixes installation variable in your stored initialization script to match your changes applied to the NSG to keep the script in sync with your actual deployment.

Uninstalling the Teams Connector

This section describes how to completely remove a Teams Connector installation, for example if you have a test system that you no longer need.

  1. Delete all of the resource groups from Azure:

    1. Identify all of your existing Teams Connector resources in Azure: in the Azure portal, for your subscription, go to Resource groups and search for the prefix that you used when naming your resources — this is the value of the $PxBaseConnName variable in the initialization script.

      You will see resource groups with names in the following formats:

      • <prefix>-TeamsBotChan-RG: this contains the Bot channel registrations.
      • <prefix>-TeamsConn-<region>-RG: this contains the Teams Connector instances (Virtual Machine scale set).
      • <prefix>-TeamsConn-<region>-static-RG: this contains the public IP address of the Teams Connector.

      If you have deployed a Teams Connector in multiple regions you will see several <prefix>-TeamsConn-... resource groups.

    2. Select each resource group in turn (with the prefix of the Teams Connector you want to delete), and then select Delete resource group and confirm with the name of the resource group.
  2. Remove the App registration from Azure:

    1. Within the Azure portal, select Azure Active Directory.
    2. Under Manage, select App registrations.
    3. Select the app registration with the prefix of the Teams Connector you want to delete, and then Delete it.
  3. Remove the Cloud Video Interop service provider from your tenant:

    1. Start a PowerShell session and run the following commands, where <tenant_name> needs to be your onmicrosoft.com domain for your tenant:

      Import-Module SkypeOnlineConnector

      $sfbSession = New-CsOnlineSession -OverrideAdminDomain "<tenant_name>.onmicrosoft.com"

      Import-PSSession $sfbSession

    2. Run the command:

      Remove-CsVideoInteropServiceProvider -Identity Pexip

  4. Remove references to the Teams Connector from the Pexip Management Node:

    1. Change or delete any locations, Virtual Receptions or Call Routing Rules that are using the Teams Connector.
    2. Go to Call control > Microsoft Teams Connectors and delete the Teams Connector address.