We have a new community! Please visit support.timextender.com

Configure your Firewall TimeXtender v20

Note: There is an updated version of this article, which applies to the next generation of TimeXtender.

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


  • 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:

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: Outbound Traffic on 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



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,


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 the web again.

worker.database-windows.net issue

You may experience this error.

Or this one.

Check the ODX Service Log and see if you can find mentions of the following address.

Error initializing server:
System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. This failure occurred while attempting to connect to the routing destination. The duration spent while attempting to connect to the original server was - [Pre-Login] initialization=6; handshake=10; [Login] initialization=0; authentication=0; [Post-Login] complete=1; The duration spent while attempting to connect to this server was - [Pre-Login] initialization=2; handshake=14992; ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out

With this error locate the bottom part of the message it may mention a server name in the message such as this.

This is one of the things Microsoft does in routing calls. It is an internal Microsoft worker server on one of their (West Europe) clusters. We don't control this. It will likely not even be for West Europe, the best we can say is that it will be *.worker.database.windows.net,* something. It will be outbound traffic on port range 11000-11999 if it is an Azure VM and 1433 outside that.

In any case, the solution is to make a rule for this in your firewall to allow for communication to the ODX Server from our Cloud repository.

Was this article helpful?
0 out of 0 found this helpful


Article is closed for comments.