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.

This topic covers the following maintenance tasks:

Modifying the Teams Connector's configuration
Upgrading the Teams Connector to the latest software
Redeploying the Teams Connector
Assigning Owner permissions for the API app
Maintaining access to the Admin Consent web page
Adding or removing Conferencing Nodes
Changing the alternative dialing instructions or IVR address
Changing the call capacity of a Teams Connector
Changing management workstation access
Mandating the use of Availability Zones
Uninstalling the Teams Connector

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).
Enabling RDP access to the Teams Connector instances (from any addresses specified in the $PxMgmtSrcAddrPrefixes installation variable).

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

When upgrading the Teams Connector to version 27, you must redeploy it using your original variables initialization script (although, if necessary, it should be updated to specify the new $tags variable introduced in v26, and you may apply any configuration changes, if required), and with the latest application software files and v27 redeployment script, as described below.

There are some important steps to be taken when upgrading your Teams Connector to version 27.

Version 27 has some specific upgrade procedures that must be completed before you redeploy your Teams Connector:
1. New Teams Connector API app: you must create a new Azure app (in addition to the existing Pexip CVI app) that is used to secure requests to the Teams Connector APIs. To do this:
  1. Run the following PowerShell command to connect to Azure AD:
    
    Connect-AzureAD
    
    Then follow the prompts to sign in to Azure AD.
  2. Run your variable initialization script to set the required prefix and region name variables.
  3. Run the following command to create the Teams Connector API app.
    Copy to clipboard
    $teamsConnectorApiApp = New-AzureADMSApplication -DisplayName "${PxBaseConnName}-TeamsConn-${PxVmssRegion} Pexip Teams Connector API" -SignInAudience "AzureADMyOrg"
    Please allow one minute for this command to complete and propagate within Azure.
  4. Run the following commands to obtain the Teams Connector API app ID.
    
    Note that if the New-AzureADServicePrincipal command fails, this means that you have not waited long enough for the previous command to complete.
    Copy to clipboard
    $teamsConnectorApiSp = New-AzureADServicePrincipal -AppId $teamsConnectorApiApp.AppId $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
  5. When the command runs, it generates some output that lists the Teams Connector API App ID, similar to this:
  6. Copy the output line that defines the API App ID ($TeamsConnectorApiApplicationId = "<your value>") and add it to the bottom of your variable initialization script (the one you ran in step 2). Thus the end of your variables script will then look similar to this:
    
    Note that your script may have values specified for the $tags variable. If required you may also want to add comment lines (beginning with #) to describe the purpose of the new $TeamsConnectorApiApplicationId variable.
    
    (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 steps above.)
  7. If somebody else will be completing the upgrade (redeployment), ensure that the person who will perform all of the remaining installation steps has Owner permissions for the new 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 Azure AD tenant. It has no associated credentials.
  - It is different from your existing Pexip CVI App which was created when your originally installed the Teams Connector, and the App ID (with its associated credentials) for that CVI app should already be recorded in your redeploy script.
  - If you have Teams Connectors in multiple Azure regions, you must repeat this process and create an API app in each region, using and then storing the app ID ($TeamsConnectorApiApplicationId) in the relevant variable initialization script for that region.
2. Variable initialization script: there are two new variables to be added to the variable initialization script:
  1. Add a new $PxBotResourceGroupName variable that defines the name of the resource group for the Azure Bot. We recommend placing it after the existing $PxTeamsConnStaticResourceGroupName variable for consistency. It should be defined as follows, to match the name of your existing Azure Bot resource group:
    
    $PxBotResourceGroupName = "$($PxBaseConnName)-TeamsBotChan-RG"
    
    (Note that for new deployments, the value assigned to this variable uses a different naming convention.)
  2. You must define a new $TeamsConnectorApiApplicationId variable as described in the previous step for the API app.
3. Scheduled scaling: this version introduces a new scaling feature to manage the capacity of your Teams Connector instances.
  
  If you currently use the Azure Event Hub for advanced status reporting, when upgrading your Pexip Infinity platform and Teams Connector to version 27 you should:
  1. Upgrade your Pexip Infinity platform as normal.
  2. Before redeploying your Teams Connector, within the Pexip Infinity Administrator interface, go to Call control > Microsoft Teams Connectors and configure the new Minimum number of instances field.
  3. Redeploy your Teams Connector as normal.
  4. After redeploying the Teams Connector you must update the connection details for the Azure Event Hub in the Pexip Infinity Administrator interface: go to Call control > Microsoft Teams Connectors and change the connection string to the Connection string–primary key associated with the pexip_teams_connector_access shared access policy.
    
    The connection string is in the format Endpoint=sb://examplevmss-lltsgzoqun-ehn.servicebus.windows.net/;SharedAccessKeyName=pexip_teams_connector_access;SharedAccessKey=[string]
    
    To find this string in the Azure portal:
    1. Go to the static resource group for the Teams Connector (this has a name in the format <prefix>-TeamsConn-<region>-static-RG).
    2. Select the Event Hubs Namespace component (<name>-EHN).
    3. From the left-hand navigation menu, under Settings select Shared access policies.
    4. Select the pexip_teams_connector_access policy.
    5. Copy the Connection string–primary key.
  Note that:
  - If Minimum number of instances is not configured, the Teams Connector will redeploy with just 1 instance (the default) and you may therefore have less capacity than you had before upgrading, although you can adjust the setting later to reinstate that capacity.
  - If you currently do not use the Azure Event Hub for advanced status reporting then you can ignore the new Minimum number of instances field and upgrade your Teams Connector as normal, and you will retain your existing capacity / number of instances.
  - If you do not update the Azure Event Hub connection string field then advanced status reporting will continue to work but scheduled scaling will not work.
The redeployment process has changed in version 27. There are some new steps to perform prior to running the redeploy script:
- To delete the existing dynamic resource group and then recreate it for the redeployed Teams Connector. Previously these steps were contained within the redeploy script.
- To ensure that the person performing the redeploy/upgrade has the Azure Owner role for the static and dynamic resource groups, and Contributor role for the Azure Bot resource group.
When upgrading from a previous major release (e.g. from v26.n to v27.4), you must use the latest version of the redeploy script as contained here. You can use your existing redeploy script if you are upgrading to a new minor/ "dot" release for the same major version (e.g. from 27.0 to 27.4).

When using a new redeploy script, update the two lines in the redeploy script that say:

$AppId = ""
$AppPassword = ""

to contain the Pexip CVI app ID and password from the version of the redeploy script you saved from your existing deployment.
You must be using Az module version 5.1.0 or later.
- To check your installed version you can run:
  Get-InstalledModule -Name Az -AllVersions
- To install the latest appropriate Az version you can run:
  Install-Module -Name Az -MinimumVersion 5.1.0 -MaximumVersion 7.3.2 -AllowClobber -Scope AllUsers
If you have deployed multiple Teams Connectors, you must follow the same redeploy process (with the appropriate variable initialization script) for each Teams Connector.
As with all upgrades, you can continue to use the Pexip CVI app from your existing deployment.

Summary of script changes between versions

Version 27

Variables script:

Contains a new $PxBotResourceGroupName variable that defines the name of the resource group for the Azure Bot. (It is located after the existing $PxTeamsConnStaticResourceGroupName variable.)
Contains a new $TeamsConnectorApiApplicationId variable that needs to be updated to store the App ID of the Teams Connector API app that you need to create as part of the upgrade process. It is located at the end of the script.)

Install script:

The Import-Module Az command now requires Az version 5.1.0 as a minimum.
In the comments the "Bot Channel registration" is now referred to as the "Azure Bot".
The commands to create the resource groups for the Azure Bot and the Teams Connector VMSS have been removed. These commands are now performed separately (prior to running the install script) to ensure that these resource groups are created with the appropriate role permissions.
The $BotChanResourceGroupName variable has been renamed $PxBotResourceGroupName (and this variable is also now defined in the variables script).
The name of the resource group that stores the Azure Bot (formerly called the Bot Channel registration) now has the format <prefix>-TeamsBot-RG (previously <prefix>-TeamsBotChan-RG).
The create_vmss_deployment.ps1 command passes a new TeamsConnectorApiApplicationId parameter (set to the new $TeamsConnectorApiApplicationId variable).

Redeploy script:

The Import-Module Az command now requires Az version 5.1.0 as a minimum.
The commands to remove the existing dynamic resource group and to recreate it for the new VMSS have been removed. These commands are now performed separately (prior to running the script) to ensure that they are recreated with the appropriate role permissions.
The create_vmss_deployment.ps1 command passes a new TeamsConnectorApiApplicationId parameter (set to the new $TeamsConnectorApiApplicationId variable).

Version 26.1

Install script: the steps at the end of the install script requesting you to set up a DNS CNAME record for your Teams Connector hostname now ask you to create a DNS A-record instead.

Redeploy script: the steps at the end of the install script requesting you to check/change your DNS CNAME record have been removed.

Previously we recommended using a CNAME record pointing to the Teams Connector's public IP address FQDN. However, this is no longer required and an A-record may be used instead. Existing deployments that use a CNAME will still work, but that can be replaced with an A record (by pointing the hostname of your Teams Connector ($PxTeamsConnFqdn) to the Public IP address of the load balancer), if you want to align your DNS process with our latest guidelines.

Version 26

Variables script: new $tags variable.

Install & redeploy script: the New-AzResourceGroup, Register-PexTeamsCviApplicationBot, Publish-PexTeamsAdminConsentWebSite and create_vmss_deployment.ps1 commands all pass the $tags variable as a -Tag parameter.

Redeploy script: the redeploy script contains a new section prior to the New-AzResourceGroup command to create the resource group for the new Teams Connector instances (VMSS). The new commands remove the dynamic Azure resource groups for you (those named <prefix>-TeamsConn-<region>-RG that contain the existing Teams Connector instances). This means you no longer have to perform this step manually via the Azure portal when upgrading or redeploying.

Version 25

Variables script: no changes.

Install/redeploy script:

Line 4 now tests that the software and script version numbers (25, in this case) match.
New command inserted at line 22 (install script) and line 12 (redeploy script):
Remove-Module "Az*" -ErrorAction SilentlyContinue
Former line 22, now line 23 (install script) and former line 12, now line 13 (redeploy script):
changed from Import-Module Az -MinimumVersion 3.0.0 -MaximumVersion 4.5.0 to Import-Module Az -MinimumVersion 4.7.0
The call to create_vmss_deployment.ps1 no longer passes the -PublicIPAddressResourceName parameter.
The steps at the end of the script to retrieve the assigned public IP address of the Teams Connector have been updated.

Lobby bypass and dialing instructions:

This now uses the MicrosoftTeams PowerShell module instead of the SkypeOnlineConnector module.

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:

Check that you have the latest relevant version of the Teams Connector software, and your variable initialization and redeploy scripts.
Delete the previous dynamic resource group and then recreate it for the new deployment, and ensure that the person performing the redeployment has the appropriate role for the resource groups in each region.
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, retrieve your original scripts, and check your Azure environment

Download the latest relevant version of the Teams Connector ZIP file (Pexip_Infinity_Connector_For_Microsoft_Teams_v27.4_<build>.zip) from the Pexip download page.

Ensure that the Teams Connector version you download is the same version as your Pexip Infinity deployment (including minor/ "dot" releases).
Extract the files to a folder on a local drive on your administrator PC.
Add your PFX certificate for the Teams Connector to this folder.
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.
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 you have the correct versions of the initialization scripts that set the regional variables to the appropriate values.
Check your saved copy of the redeploy script:
- If you are upgrading to v27, ensure that you use the latest version of the redeploy script instead of your previously saved copy, but that you have updated it with your Pexip CVI App ID and credentials from your previously saved copy, as described immediately below.
- Confirm that the redeploy script contains your Pexip CVI App ID and credentials:
  - When the installation script ran, it generated some output that listed the CVI 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 CVI app and password that you created the first time.
- You should use the 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 the redeploy 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 and then recreate the dynamic resource group and ensure appropriate roles are assigned to the resource groups

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

Run the following PowerShell command to connect to Azure:

Connect-AzAccount

Then follow the prompts to sign in to Azure.
Run the variable initialization script that you used when your first installed the Teams Connector (to set the required subscription, resource group name and region variables).
Ensure that you are using the Azure subscription for the Teams Connector:

Set-AzContext -SubscriptionId $PxSubscriptionId

Run the following script. It first deletes the existing dynamic resource group and then recreates it for the new/redeployed Teams Connector.

Copy to clipboard

# Remove the existing dynamic resource groups
$PxTeamsConnResourceGroup = Get-AzResourceGroup -Name $PxTeamsConnResourceGroupName -Location $PxAzureLocation
if ($PxTeamsConnResourceGroup)
{
    $resources = Get-AzResource -ResourceGroupName $PxTeamsConnResourceGroupName
    $resNames = $resources | ForEach-Object {return "`n" + $_.Name + " " + $_.ResourceType}
    Write-Host "In order to redeploy Pexip Teams Connector, resource group $PxTeamsConnResourceGroupName has to be deleted. Resources: $resNames"
    Remove-AzResourceGroup -Name $PxTeamsConnResourceGroupName | Out-Null
}
$PxTeamsConnResourceGroup = Get-AzResourceGroup -Name $PxTeamsConnResourceGroupName -Location $PxAzureLocation -ErrorAction SilentlyContinue
if ($null -ne $PxTeamsConnResourceGroup)
{
    Write-Warning "$PxTeamsConnResourceGroupName still exists, however it has to be removed before redeploying!"
}

# Create Resource group for Teams Connector VMSS (per region)
# This region specific, ensure that the initial variables are set with the
# correct values for $PxAzureLocation, $PxTeamsConnFqdn and $PxVmssRegion
New-AzResourceGroup -Name $PxTeamsConnResourceGroupName -Location $PxAzureLocation -Tag $tags

Ensure that the person performing the redeploy/upgrade has the Azure Owner role for the static and dynamic resource groups, and Contributor role for the Azure Bot resource group. If you have deployed in multiple regions you must do this for all of the resource groups in each region.

If the Owner of the Azure subscription will be performing the redeploy/upgrade then this step can be skipped, otherwise the subscription Owner must assign the required roles to the person performing the upgrade. You do this by running the following commands:

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

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

New-AzRoleAssignment -SignInName <email_name> -RoleDefinitionName "Contributor" -ResourceGroupName $PxBotResourceGroupName

where <email_name> is the email address / user principal name of the person who will perform the remaining upgrade/redeploy 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:

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.

Redeploy the Teams Connector

To redeploy the Teams Connector:

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.
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.

This script applies to software version 27. If you are using an earlier version you should refer to our previous documentation.

Do not use Az version 7.4.0 or later to install the Teams Connector as this will lead to deployment failures. You can use Get-InstalledModule -Name Az to check your installed version.

Copy to clipboard

# Ensure the correct script and software combination is being used
try {$PxConnMajorVersion = (Get-Content .\version.json -ErrorAction Stop | Out-String | ConvertFrom-Json).major} catch {Write-Warning "Can't find version.json file. Make sure you run the installation script from the folder into which you extracted the files from the Teams Connector ZIP"}

if ($PxConnMajorVersion -ne "27"){Write-Warning "The Connector version (extracted ZIP files) and this deployment script version do not match. Connector version = $PxConnMajorVersion. Deployment script version = 27"}

# Connect to PowerShell Azure Resource Manager account
# Set execution policy for the current PowerShell process, when prompted type A (Yes to All)
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

# Connect to Azure with an authenticated account for use with Azure Resource Manager (in same window to reuse variables)
# If the Import-Module step fails, ensure you have a suitable version of Az installed (5.1.0+)
Remove-Module "Az*" -ErrorAction SilentlyContinue
Import-Module Az -MinimumVersion 5.1.0
Connect-AzAccount

# Before running the following commands, update the following 2 lines/variables with the CVI 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-AzContext -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 did not want to specify the password as a variable, use Get-Credential
# $PxWinAdminCred = Get-Credential

# 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 -IncidentReporting $PxTeamsConnIncidentReporting -RdpSourceAddressPrefixes $PxMgmtSrcAddrPrefixes -PexipSourceAddressPrefixes $PxNodesSourceAddressPrefixes -WupdScheduledInstallDay $PxWupdScheduledInstallDay -WupdScheduledInstallTime $PxWupdScheduledInstallTime -WupdActiveHoursStart $PxWupdActiveHoursStart -WupdActiveHoursEnd $PxWupdActiveHoursEnd -CustomerUsageAttribution $PxCustomerUsageAttribution -Tag $tags -TeamsConnectorApiApplicationId $TeamsConnectorApiApplicationId

# supply the PFX certificate file password when prompted

# Please enter the password for the PFX certificate '.\xxxxxxxx.pfx': ***************

# Printing finished message
Write-Host
Write-Host
Write-Host "`n--------------------------`n"
Write-Host
Write-Host " All steps completed."
Write-Host
Write-Host "`n--------------------------`n"
Write-Host
Write-Host

Assigning Owner permissions for the API app

The person who will be performing the deployment must have Owner permissions for the API app.

When necessary, the following script can be used by the current Owner to assign the Owner permission to another user.

Note that you must have run the variables script to assign the $TeamsConnectorApiApplicationId variable and you must replace <email_name> in the script with the email address / user principal name of the person who will perform the remaining installation steps.

Copy to clipboard

# Get the API application registration reference
$apiApp = Get-AzureADApplication -Filter "AppId eq '${TeamsConnectorApiApplicationId}'"

# Get the assignee
# Note that in case of external users (guests in a tenant) the -ObjectId parameter is in form "<email_name>#EXT#@<tenant_url>"
$user = Get-AzureADUser -ObjectId <email_name>

# Assign owner role for the API application registration to the assignee
Add-AzureADApplicationOwner -ObjectId $apiApp.ObjectId -RefObjectId $user.ObjectId

# Get the service principal associated with the API application
$apiAppSp = Get-AzureADServicePrincipal -Filter "AppId eq '${TeamsConnectorApiApplicationId}'"

# Assign owner role for the API application service principal to the assignee
Add-AzureADServicePrincipalOwner -ObjectId $apiAppSp.ObjectId -RefObjectId $user.ObjectId

Maintaining access to the Admin Consent web page

Reinstating the Admin Consent web page

If you are upgrading 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

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

and then

Write-Host "To give consent to the CVI 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.

Changing the workstation / management network addresses that can access the consent page

To change the workstation / management network addresses that can provide consent for the Teams Connector CVI app (the addresses that were initially specified in $PxConsentSourceAddressPrefixes):

In the Azure portal, go to the Azure bot resource group — this is called <prefix>-TeamsBot-RG.
Select the App Service object.
Under Settings, select Networking.
Select Configure Access Restrictions.
Modify the addresses as required and save your changes.

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:

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 signaling then the example certificate naming policy used here is more appropriate.
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.
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 CVI 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, or if you have enabled the Azure Event Hub you can also automate/schedule changes in call capacity to suit your requirements.

See Scheduling scaling and managing Teams Connector capacity for full details.

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. If you want to subsequently allow RDP access you must do a full redeploy. You cannot just convert the Deny rule into an Allow rule (as other associated Teams Connector settings also have to be modified).

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

In the Azure portal, for your subscription, go to the Network security group in your Teams Connector resource group.
Select rule 1000 RDP.
Change the Source IP addresses/CIDR ranges as appropriate for the management workstation / network subnet addresses you want to allow RDP access.
Select Save.
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.

Mandating the use of Availability Zones

By default the Teams Connector uses Azure Availability Zones if they are available in the selected region. However if you want to mandate the use of Availability Zones you can add an extra parameter to the call to create_vmss_deployment.ps1 in your installation/redeployment script.

The parameter is -UseAvailabilityZones and can be set to either "BestEffort" (the default) or "Mandatory".

If you use "Mandatory" and Availability Zones are not available in the selected region then the deployment will fail with an error: "Availability zones not available for the selected region or the VM type is not available in the availability zones". See Azure regions with Availability Zones for the list of supported regions.

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.

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>-TeamsBot-RG: this contains the Azure Bot. (If your Teams Connector was installed prior to version 27 then the name uses the format <prefix>-TeamsBotChan-RG instead.)
  - <prefix>-TeamsConn-<region>-RG: this contains the Teams Connector instances (Virtual Machine scale set).
  - <prefix>-TeamsConn-<region>-static-RG: this includes the Azure Key Vault and 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.
  
  Note that as from v26, the Azure Key Vault is only soft-deleted when the static resource group is deleted. This means that if you subsequently redeploy your Teams Connector using the same variables initialization script, you will encounter deployment errors due to conflicts with key vault object names. To avoid this you must first purge the soft-deleted key vault:
  1. Go to the Key Vaults services within Azure.
  2. Select Manage deleted vaults.
  3. Select the subscription and purge the key vault.
Remove the App registrations from Azure:
1. Within the Azure portal, select Azure Active Directory.
2. Under Manage, select App registrations.
3. Select the two app registrations (the CVI app and the API app) with the prefix of the Teams Connector you want to delete, and then Delete them.
Remove the Cloud Video Interop service provider from your tenant:
1. Start a PowerShell session and run the following commands to sign in to your Teams tenant:
  
  Import-Module MicrosoftTeams
  
  Connect-MicrosoftTeams
2. Run the command:
  
  Remove-CsVideoInteropServiceProvider -Identity Pexip
  
  To run the command, you need the Global administrator role.
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.
Remove from DNS the record that refers to the FQDN of the Teams Connector load balancer.