How to set up TimeXtender Desktop on a local Machine

Hi ​@TXODX 

This is a firewall issue. The sql server mentioned in the error is the one where your repository database is located.

​@Thomas Lind thanks for the quick response.  I have run test-netconnection on these and they have all passed with TRUE. 

I am no expert in firewall setups, but this is a common error in support. It usually eventually ends with the firewall somehow blocking the access.

When exactly did you get this? I assume you only run TimeXtender Data Integration on your VM. 

The Ingest Service should run on its own server and then your VM will be used to connect to that service.

We have a VM that is running the ODX.  I also installed the TX data integration application on that VM and am able to do developlement there without issue.  

Today I installed the TX data integration application on my local machine.  We would like to have the developers (myself and my colleague) running this application locally with the ODX service running on the VM.

Hi,

your Ingest / TDI VM likely has a different networking route to TX's remote repositories than your local machine. Sometimes those errors are transient, I get that exact error sometimes in SSMS when connecting to Azure SQL Databases in the same VNET from a VM but can then retry.

You may need to change either your Windows firewall on your local machine or have your network team check whether your traffic makes it through your firewall. It could be that the return messages from the remote repository use dynamic ports and don't make it back properly for instance.

Thanks ​@rory.smith  - I am checking internally with our team.  For us it does not seem to be a transient error.  Have not been able to get past it at all.  

Hi ​@TXODX 

Your server can run the Ingest/ODX Instance fine on the VM, right?

So you get this error when you open TimeXtender Data Integration and attempts to open that instance?

What are you running this instance as in regards to servername and port?

It needs to run as the VMs DNS name to be able to connect to it from a remote location.
 

Hi ​@TXODX Just following up on this - could you please provide the details requested above?

Hi all,

Sorry was out with sick kids since last Friday.  I spoke with our communications team and they said that *That we need to make an opening for all communications that goes outside Ovako.  We need to know which destinations or servers need to be opened on the local machines in order to make the connection to the VM.

​@Thomas Lind to answer your questions above:

1. Yes our I can run the ingest/ODX fine on the VM.
2. Yes I get this message on my local machine when trying to open the instance.
3. Do you mean my local instance or the VM instance in regards to server port an name?

-Mark

Hi,

in your ODX Server definition the ‘server’ parameter needs to be a hostname or ip address that can be reached from your client machine. I.e., if you set it up as . or localhost it will not work as your client will be looking inside itself for an ODX that is hosted elsewhere.

Your client machine will be attempting to connect on the port you specify the ODX running under, any responses from the ODX back might be caught up in a firewall if it is set up to be strict.

Where do I find the ODX server configuration.  According to documentation in should be in the tools > options > ODX server tab.  I dont see that:  

Hi,

on your VM running the ODX Server open TimeXtender and look in the options menu or click on the repository in the status bar at the bottom. You cannot see it from your client machine as it cannot yet reach your ODX.

That screen shot was from my VM.  I can’t find it there.

Is your ODX Service running on the VM at the moment? Have you run the ODX Configuration tool when setting up TimeXtender?

Yes I have and the ODX service is running 

Missed you were running the 6xxx release. In that case your infrastructure definitions are in the portal. Your Ingest instance is the one to look for (or run the Ingest config tool again).

Okay found it...checking with the communications team if they can see something that is being blocked.

Does the VM server need to be able to communicate with anything else when I am trying to connect via my local machine?

Hi ​@TXODX 

Not when you connect to the Virtual Machine that runs the Ingest / ODX Server Service.

The communication will be done towards the port and server you have set in the portal.

Hi,

you should be able to do something like the following in Powershell to test if a network connection can be made to that port:

Test-NetConnection <hostname defined in portal> -port <portnumber defined in portal>

If that fails, it is good to see if the failure is due to resolving the name not working:

nslookup <hostname defined in portal>

If the hostname resolves, but the test-netconnection fails it is a firewalling issue.

If both succeed, but connecting to the Ingest fails, it might be down to TLS settings on your client machine or similar. Checking EventViewer for additional logging might be useful.

Hi,

I just ran both tests and they went through without any issue.  

Hi ​@TXODX have you had a chance to test the above?