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:
- sql-instances-prod.database.windows.net
- 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:
- traws.timextender.com
- Port 443
- Sign-in to Desktop, ODX configuration
- timextender-saas.eu.auth0.com
- Port 443
ODX Server
- 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
- Ensure that inbound rules are added for the ports used for the ODX instances
Additional servers
- auth0.com Port 443
- eu.auth0.com Port 443
- cdn.auth0.com Port 443
- app.timextender.com Port 443
- app-encryption-prod-001.azurewebsites.net 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 sql-instances-prod.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:
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.
worker.database-windows.net 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 *.worker.database.windows.net,* 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.
