Can log into TM1 Web but not Architect

[John Hammond]

I have a combination of 2 factors in my TM1 set up.

Factor 1: 32 bit or 64 bit Server
Factor 2: LAN access or Remote WAN access via NAT address through open firewall

All 4 combinations of Factor 1 and Factor 2 are in play and they all work fine with the exception of

64 bit Server and Remote WAN access via NAT address through open firewall (let's call this Option 4)

The problem in architect is that the list of servers attached to the admin server is successfully displayed. However when I double click on a server to access it, instead of an immediate prompt for credentials, I get a 10 second or so wait and then no error message is displayed. For the other 3 combinations the prompt is immediate and then I get the tree beneath the server.

If I try to log in with Option 4 via the tm1web url http://server/TM1Web/TM1WebLogin.aspx then I can do so with no problems and have successfully run reports.

Stuff I have tried is setting SSL off, but this does not make a difference.

Any ideas would be greatly appreciated.

[John Hammond]

I have just tested all of the ports necessary to check if it is a firewall/blocked ports issue having looked at other posts.

- admin server port
telnet server 5495

- admin server ssl port
telnet server 5498

-server port
telnet server 12345

And all produce a connect which is a repeated underscore. So no probs there...

[David Usherwood]

I'm away from my office but from memory, if you are putting TM1 through a firewall, you need to put the IP address of the firewall box (as well as the 'real' address) in the CFG file. It's a while since I looked at this though.

Web is working fine because you are talking to the web server and it is talking to the TM1 server (via the Admin server).

[John Hammond]

Just come in early to try an idea I had.

Registered the 64bit server with 32 bit admin. This took several restarts of services but it did eventually work. However when tried on option 4 had same problem.

David Usherwood - thank you very much for your input.

I think this makes sense. I think what is happening is that we are interrogating the admin server as to the IP address of the server. The admin server is responding with the IP address of the local system whereas the remote system requires the NAT'ed IP Address. This explains why we have the 10 seconds delay while we continuously try to contact the server on the wrong IP address.

I will now look along these lines to see if we can get the admin to return the 2 ip addresses or we may have to aim for a system where the IP address and the NAT'ed ip addresses are identical.

[John Hammond]

Thank David - this is what it took

#jph required for 64 bit
IPAddress=10.250.6.110;10.19.207.21

IPAddress Optional This parameter lets you specify multiple IP addresses for an individual TM1 server. For example, a server can use one IP address for clients within a firewall and a different IP address for clients outside the firewall.

The following example specifies two IP addresses for a TM1 server:
IPAddress="130.5.32.0; 130.5.64.0"
Note that the addresses must be enclosed in a single set of quotation marks and separated by a semicolon.
When you specify multiple IP addresses for a server, the associated Admin Server recognizes all addresses but displays only the first IP address in the Admin Server window.

[Steve Vincent]

Interesting, is that suggesting that WAN performance in general could be improved simply by specifying both the internal and external IPs to the admin server?

[John Hammond]

Steve

If we dont consider the effect of the IP address parameter.

It seems 32 bit TM1 works this way.
"Get the IP address of the server from the admin server. Try using that ip to establish connection with the server. If not then use the IP address of the admin server."

But 64 bit TM1 works this way.
"Get the IP address of the server from the admin server. Try using that ip to establish connection with the server. (no catch all of using the admin IP)

In either case

Once the connection is established that IP that connected will be used thereon.

So there will be a small initial cost of trying out wrong IP addresses but once connection is established it will no longer look at alternatives. So the answer is there is unlikely to be any performance improvement, I am afraid.

I thought the same thing as you - an unforseen way to speed things up but alas it was not so!