Gallery Systems did some debugging with me last Friday. It looks like it may be a DNS problem on our system – our DB server has two different “names” that both point to it.  Nothing illegal about that, but we were using one of those names when we configured ODBC on the client workstations, but the DB server viewed its own name as the other one.

 

An interesting thing about the TMS client is that when you first log in, it is using ODBC. But as soon as a connection is made via ODBC, it switches to a different protocol, OLE-DB. The initial connection was being made ok, but the problem happened during the switch. We could tell something funny was going on because of the problem described in my first message – a logon with an incorrect password would fail immediately – indicating that a link to the server was being made. But when the logon had the proper credentials it would hang for 30 seconds or so before failing.

 

Anyway, it seems that problem is solved now by configuring the problematic client hosts file with both of the DB server names.

 

Thanks all. -Steve  

 

 

-- 

Steve Rothman, Systems Administrator

Peabody Museum of Archaeology and Ethnology

 

 

From: Museum Users <[log in to unmask]> on behalf of Steve Rothman Work <[log in to unmask]>
Reply-To: Museum Users <[log in to unmask]>
Date: Friday, May 10, 2019 at 10:45 AM
To: Museum Users <[log in to unmask]>
Subject: Re: Difficulty using TMS client via wifi & VPN?

 

I’m afraid I didn’t explain well. We’re not using remote desktop, in most cases. When we do use remote desktop, it works fine.

 

We install the TMS client software directly on our client computers. That’s where the problem lies. The TMS client on the computer works fine with ethernet+VPN, will not work with wifi+VPN.  -Steve

 

 

-- 

Steve Rothman, Systems Administrator

Peabody Museum of Archaeology and Ethnology

 

 

From: Museum Users <[log in to unmask]> on behalf of Steven Moore <[log in to unmask]>
Reply-To: Museum Users <[log in to unmask]>
Date: Friday, May 10, 2019 at 10:40 AM
To: Museum Users <[log in to unmask]>
Subject: Re: Difficulty using TMS client via wifi & VPN?

 

 

Remote Desktop requires TCP port 3389 to be open. Sounds like Wifi network does not allow RDP traffic.

 

Steven MOORE

Developer & Database Administrator

Department of Information Technology

 

The Museum of Modern Art

11 West 53 Street

New York, NY 10019

813.240.0587


Image removed by sender.

 

 

On Fri, May 10, 2019 at 10:32 AM Rothman, Steve <[log in to unmask]> wrote:

Hi, we’re using TMS 2016r2. We install the TMS client directly on our desktops and laptops (if they’re Windows) otherwise we use Remote Access.

 

If our desktops & laptops are connected to our main LAN via ethernet, they can access TMS just fine.

 

If they are on ethernet, but on a different LAN, we need to use a VPN that has been set up, and that works just fine.

 

But when our laptops are using wifi, even though they use the exact same VPN configuration that works on ethernet, TMS will not connect – we get the dreaded “Connection Failed” message. Clearly it’s reaching the server though – if I deliberately put in the wrong password I get the connection failed message immediately, but if everything is correct on the login window then in takes about 30 seconds to get the connection failed message. So the TMS client is definitely reaching the server for some initial connection, but something goes wrong that point.

 

I’ve confirmed that port 1433 is open for VPN (and of course it must be since VPN works ok on ethernet).

 

Any ideas about what else may be failing when using VPN over wifi when VPN over ethernet works fine? Recommendations for further troubleshooting?

 

-Steve

 

-- 

Steve Rothman, Systems Administrator

Peabody Museum of Archaeology and Ethnology

 

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

signoff TMSUSERS

// eoj

You will receive a confirmation that your subscription has been removed.

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

signoff TMSUSERS

// eoj

You will receive a confirmation that your subscription has been removed.

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

signoff TMSUSERS

// eoj

You will receive a confirmation that your subscription has been removed.

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

signoff TMSUSERS

// eoj

You will receive a confirmation that your subscription has been removed.