Can you register multiple admin hosts on one physical server?

[nmcdermaid]

Can you register multiple admin hosts on one physical server?

From brief research I don't think this is possible as it appears the TM1 server looks for a single specifically named service.... though how it does that over a network I'm not sure.

Anyway here's my specific problem:

We'll probably have one combination dev/test server and one prod server. When I say server I mean an actual machine name on the network as opposed to TM1 server containing cubes etc.

In my explanation below I'll call a TM1 server a 'database'

In dev we will have a database called 'MyDatabase'

Then we will want to migrate that to the test environment, I assume by copying objects between database folders.

Since the test environment is on the same server and using the same admin host, we'll need to call the test database something else like 'MyDatabase_TEST'


I assume (not verified), that now that I've changed the logical name of the database, some references inside the database will no longer work as they would be referencing the old name.


So I'm wondering if its possible to register two admin hosts on the one server and effectively partition dev and test on one server, and therefore allow me to have databases with the same name.

It appears that the TM1S.INI file only refers to an admin server name so I think I can only have one admin host per physical server.

[dusherwo]

Confirmed - you can't have two different admin hosts running on the same box. But, fortunately, your assumption that moving TM1 objects to another server will break references is not correct. I can't think of any references to server names, probably because TM1's inter-server capabilities are more or less non existence. References to files in TIs (reading or writing) would need updating, or you can store them in cubes.

[nmcdermaid]

Thanks for your response.

So I shouldn't be worried about seeing this:

mop:Data Entry - Daily->Export

in the 'data source name' in a TI process that transfers a cube view into a text file.

In the above string, mop refers to the 'server'. If I was to follow the above procedure, the database would be called mop_test. Do you think it would break the TI process?


I notice that behind the scenes when I use local variables, it doesn't actually need the mop part... so I guess I can disregard it.


Thanks for your help.

[nmcdermaid]

oh... and I almost forgot... you'll have to forgive me for not even trying this yet but its probably quicker to ask.....

If I have an Excel 'slice' pointing at ADMNIHOST1, Server: mop, and I want to 'migrate' it into test and point it at mop_test, is that difficult?

[OLAPBPMguy]

A cube view data source reference is by definition an internal database reference so if the database container name changes (from mop_dev to mop_prod for example) then as long as the cube name is constant then your process will be OK nothing will change.

In terms of the Excel slice scenario the Perspectives client or web client will never "see" an admin host reference only a server:cube or server:dimension pair so you don't need to worry about admin hosts in the UI.

TM1 databases can register with more than one admin host. (In fact often this is necessary for certain replication setups.) But a single admin host can only register servers with unique port numbers and unique server names on a first come first served basis.  So if you do want to preserve the same server name in both environments then a separate admin host is necessary.  Note that the admin host itself requires virtually nill resources and could be on any networked server, it is perfectly feasible to have 2 databases of the same name using memory and CPU resources on the one physical server as long as at least one of the databases is pointing to an alternate admin host.

Getting back to your Excel slice question, for a method to work with multiple databases in an Excel or websheet UI have a look here.