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.
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: 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
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 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.
0 Comments