Citrix/Terminal Services

[AmbPin]

Hello,

I am looking at rolling out TM1 around our sales offices around Europe and USA, does anyone have any advice as to whether I should let people connect from locally installed desktop tools to the UK server or if I should look at Citrix/Terminal Services?
I would be grateful for any advice or experiences (good or bad).

[Martin Ingram]

You'll probably find connection to the UK server directly via a locally installed client is really only a workable solution over a LAN.

We have a TM1 server installed in London, with users distributed worldwide. Non-London users (until now - see below) have always connected to the London server via Citrix - this, or Terminal Services, seems to be the default deployment method for multi-site implementations where there is the desire to maintain a single, centralised server.

Off the top of my head, some of the benefits and pitfalls of Citrix are as follows;

BENEFITS
Can maintain a single instance of TM1 on one server (simplicity of TM1 implementation)
Easier to upgrade - only need to change client software on the Citrix machine (& server)
Ability to shadow users (great for helping users with functionality issues)

PITFALLS
Connection is vulnerable to latency or dropping out where there are bandwidth limitations
Needs configuring to allow users to see their usual network drives, use of printers etc
Takes forever for users to open a file stored on their local network onto the Citrix server (despite attempts to re-educate users in the use of application folders or storing files on the London network, a lot of them still struggle)
Where TM1 and/or Excel hang, it can be tricky for the user to kill their session and restart Excel - more often than not they need IT to intervene to kill citrix session

The extent to which the Pitfalls come into play will be dependent on the level of expertise in your IT group (and bandwidth)

ALTERNATIVES

REPLICATION - an alternative is to place an additional server(s) in other offices, then synchronise the data and structures on those servers on a scheduled (eg overnight) or adhoc basis as required.
This solution seems to get quite a slating on these forums - the interface for setting the functionality up is quite poor and useful documentation almost seems to be non-existant.
However, from my limited experience, I've found that if the replication is carefully thought out and implemented correctly, it can work quite well.
For my current client, we are piloting a replicated solution in the Aberdeen office and so far so good (touch wood!)

WEB - Maybe an option? The main downside in my experience has been that you miss out on most of the functionaility available in an excel-integrated solution. As you mention Sales offices below, the excel environment may not be so important for your target user?

Try a search on older topics on here as all of these approaches (inluding Citrix) have been discussed extensively before

[AmbPin]

Thanks for your reply Martin

I was particularly interested in your suggestion regarding replication; I have tried this before but decided to give it another go. I set this up between two machines in our UK office, changed data on both and ran a data load on one and the data seemed to sychronize as expected. I then tried between UK and San Diego; first off the replication would not copy the structures over at all, so I copied the model across and noticed that the synchronize data tasks were taking at least 20 minutes where they had taken seconds in the same office. Obviously there is a long way for the data to travel but the network utilization must be very poor for the times to be so different; we observed that the data is sent across in such small packets each of which is affected by the latency hence the long sync times.

We also observed that some data did not get copied across which we suspect was due to a save operation curtailing the log on the source machine. The replication process seems to have potential but does not seem sufficiently robust, I would be most interested to hear how you get on with your implementation.

[Martin Ingram]

Hi AmbPin -

Replication between remote locations will inevitably be slower than within the same office due to the distance travelled, bandwidth etc etc. Some of the things I've found are noted as follows, which may or may not be of use to you in troubleshooting / tweaking your replication set-up - note that I've only ever done this on 9.4.1;

1 - Don't try to set the replication up across the WAN - this seemed to take ages for us or would fall over - it was much easier to set up the relationship between 2 databases, both in London, then move one of the databases up to Aberdeen once the relationship was in place.

2 - Take screen dumps of your set-up- the settings you specify in the 'Replicate Cube' window have the annoying habit of appearing to return to default if you ever try to come back and view them again - so as you set things up, make sure you keep a record of what it is that you've done.

3 - Think carefully about the Replication user ID - what gets synchronised is largely determined by the security settings of the user ID you specify for the replication. Our cubes are largely populated by 'actuals' - however, we can easily populate both Aberdeen and London databases with Actuals entirely independent of eachother - hence there is no need to replicate actuals => The user ID we specify for the replication has no access to Actuals so no Actuals data is replicated (saving considerable time)

4 - Remember that Replication uses Log Files - what gets synchronised is based upon changes to log files since the last time replication has been run; You may have a situation where you've amended the security of the ID that's used for replication, but the data you need still hasn't come across - this will be because the log files haven't changed so TM1 doesn't see the need to synchronise anything (which brings me on to point 5!)

5 - Set up a routine to 'force' replication - in circumstances such as in point 4, you may need to force an update to the log files so that TM1 replicates data the next time that synchronisation is run - a simple TI process to export all of the cube data, zero the cube, then import the data back in will do the trick. This can also be brought into play in the event that the replication 'falls over' etc (this has never happened to me)

6 - create a reconciliation report and review it regularly - we have an XL report that draws data from both our Aberdeen and London servers for integrity checking - it takes a couple of minutes to access the Aberdeen check totals across the WAN. We actually have reasonably complex 2-way replication going on, and checking this report in the days following the implementation was useful in identifying initial teething issues.

7 - Don't replicate Cube views and subsets unless you need them - each view or subset seems to add a second or two onto the time our synchronisation takes to complete - we don't include views or subsets unless absolutely necessary.

There's probably more I could tell you, but if you have some more specific questions, I'll be happy to reply

[iansdigby]

You may find this information useful.

Our busiest user found the TM1 9.4.1 client too slow to work remotely over a VPN, so he used TM1 over Citrix and found this very acceptable. However, the 9.5.1 client seems to work much faster than 9.4.1, making this a feasible option without using Citrix. Not saying this is universally applicable, just that it is worth investigating.

Regards, Ian Digby, Meggitt

[AmbPin]

Thanks for that, I have just set up a 9.5.1 server so will give that a go.