Configure your Firewall

  • 27 December 2022
  • 2 replies
Configure your Firewall
Userlevel 3
Badge +3

Relates to TimeXtender 6024.1 and later versions

The following list of servers and ports used by TimeXtender and ODX Server should be opened in your firewall settings.

TimeXtender Desktop

To use the new version of TimeXtender, the desktop software needs to be able to reach these URLs:

  • Instance databases:
    • Server is outside Azure (On-Prem): Port 1433 standard for SQL Server
    • Server is Inside Azure: Port range 11000-11999
  • Client secret authentication, data sources provider download and updates:
    • Port 443
  • Sign-in to Desktop, ODX configuration
    • Port 443

ODX Server

  • Updating CData components:
    • Port 443
  • If using Azure Data Lake Storage
    • <storage account name>
    • Port 443
  • If using Azure Data Factory Data Sources
    • Port 443
  • Ensure that inbound rules are added for the ports used for the ODX instances

Additional servers

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


Turn off services in Subnet setup

In certain Virtual Network scenarios, after enabling the above connections, TimeXtender Desktop may still be unable to access the TimeXtender server in the cloud.
If your App server is on an Azure Virtual Network, review the Subnet setup and check if there is any blocking setting using the Microsoft.Web service endpoint.

Connect to the Virtual Machine you use as App server -> examine the Virtual network/subnet

Click on subnet to get the following menu.



Remove the Microsoft.Web service endpoint by clicking on the Delete icon.

Save the new configuration.

This may resolve the access issue. issue

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 *,* something. It will be 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.

2 replies

I have a customer who uses an on-premises virtual machine with no internet access. We added the above firewall rules as a preparation step.

Turns out this list is not exhaustive, you need to add more to the firewall whitelist, to make the login process work correctly:


So you need to add these 5 rules to the firewall as well, besides the list above.

Userlevel 3
Badge +3

Thank you Hans. The article has been updated.