Below is a list of servers and ports used by TimeXtender and ODX Server that should be opened in your firewall settings.

TimeXtender

• Product Activation via License Key:
  • selfservice.cloudapp.net
  • Port 80
• Repository Upgrade Web Service:
  • services.timextender.com
  • waws-prod-am2-055.cloudapp.net
  • Port 443
• Updating CData components:
  • api.timextender.com
  • Port 443
• Multiple Environment Remote & Local Ports:
  • These are configured by the user when setting up Environment Properties.

ODX Server

• ODX Server Repository:
  • timextender-repositories.database.windows.net
  • Server is outside Azure (On-Prem): Port 1433 standard for SQL Server
  • Server is Inside Azure: Port range 11000-11999 See Microsoft Doc for more info
• ODX Secret Validation:
  • timextender-api.azurewebsites.net or api.timextender.com
  • waws-prod-am2-061.cloudapp.net
  • Port 443
• Updating CData components:
  • api.timextender.com
  • Port 443
• If using Azure Data Lake Storage
  • <storage account name>.dfs.core.windows.net
  • Port 443
• If using Azure Data Factory Data Sources
  • management.azure.com
  • Port 443

Troubleshooting

Test-NetConnection

You can use the Test-NetConnection command in Windows PowerShell on the application server to test your machine's connectivity to the above servers and ports. 

As an example, you can copy and paste the following command into PowerShell then hit ENTER to execute:

Test-NetConnection timextender-repositories.database.windows.net -Port 1433

Change the Server Name and Port (if necessary) to test any of the above-required network connections for TimeXtender. 

This is how the command and results should appear in PowerShell:

Allow SOAP communication through the firewall

Our activation of the license key is done via SOAP,

https://docs.microsoft.com/en-us/windows/win32/cossdk/com--soap-service-security-considerations

By default, unencrypted SOAP communications are received at the HTTP port (80) and encrypted SOAP communications are received at the HTTPS port (443). For a client to successfully access an XML web service, any firewalls between the client and the server must be configured to allow TCP SYN packets to reach the appropriate server port. Conversely, to limit access to XML web services, a firewall administrator may choose to close these ports.

So be sure that sort of communication is allowed through the firewall.

Turn off services in Subnet setup

It was found that at times you could get a successful connection to the server but still not have access to the repository server.
This was happening for a server on an Azure Virtual Network. The blocking setting was the Microsoft.Web Service Endpoint that was added to the Subnet setup.

You start by connecting to the Virtual Machine you use as App server and going to the Virtual network/subnet

In there you click on subnet to get the following menu.

Here you need to remove the Web service endpoint by clicking on the Delete icon and saving.
This should allow you to have access through web again.