Before running the following script you need to setup a chore with a TI process to execute that line in Prolog:

SaveDataAll;

/!\ Avoid using the SaveTime setting in tm1s.cfg as it could conflict with other chores/processes trying to run at the same time

here is the DOS backup script that you can schedule to backup your TM1 server

netsvc /stop \\TM1server "TM1 service"

sleep 300

rmdir "\\computer2\path\to\backup" /S /Q
mkdir "\\computer2\path\to\backup"
xcopy "\\TM1server\path\to\server" "\\computer2\path\to\backup" /Y /R /S
xcopy "\\TM1server\path\to\server\}*" "\\computer2\path\to\backup" /Y /R /S
netsvc /start \\TM1server "TM1 service"

The Performance Monitor in TM1 is a great tool to gather helpful statistics about your system and pinpoint all sorts of bottlenecks.

You can start the Performance Monitor in 2 ways:

• In Server Explorer -> Server -> Start Performance Monitor
• add PerformanceMonitorOn=T in tm1s.cfg, this is a dynamic parameter, it will come into action within 60 seconds

Once performance monitor is turned on, it starts populating the }Stats control cubes and it updates them every minute.
Well, so far so good...
BUT by default in TM1, ALL cubes in }CubeProperties are set to log ALL transactions. That seems like a sane default, nobody wants to lose track of whom, when and by how much changed a cell in a cube.
So by default, the Performance Monitor will start spamming the transaction log, every minute of your entire server uptime. The problem is most acute with }StatsByCube, it logs one line for every cube, and for every }Element_Attributes_dimension cube.

There is a simple remedy: turn off logging in }CubeProperties for all }Stats cubes (IBM documentation is incomplete)
A quick Turbo Integrator process can do the job too:

CellPutS('NO', '}CubeProperties', '}StatsByClient',       'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsByCube',         'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsByCubeByClient', 'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsByRule',         'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsByProcess',      'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsByChore',        'LOGGING');
CellPutS('NO', '}CubeProperties', '}StatsForServer',      'LOGGING');

The size of the spamming may only be a few megabytes per day, although it will have an impact on how long your transaction searches take. Also, the transaction log doesn't rotate for a good reason: you don't want to lose valuable transactions. So it will happily fill up the local drive and after a few months or years the server will finally crash.

If you haven't noticed the issue until now, all is not lost. You don't have to keep all this spam thanks to this bash one-liner that will clean up your 50 gigabyte logs:

for f in tm1s20*log; do awk -F, '$8 != "\"}StatsByCube\""' "$f" > "$f".tmp && mv "$f".tmp "$f"; done # one line to rule them all

You will notice it is removing only "}StatsByCube". I could have added the other }StatsBy cubes, but these are literally 2 orders of magnitude less spammy than }StatsByCube on its own.

Challenge for you: try to achieve the same as the bash one-liner above in any language in less than the 79 characters above. I made it easy, I left a lot of superfluous characters. Constructive comments and answers are welcome.

 

section dedicated to documenting TM1 with different techniques and tools.

Pointing all your users to a single TM1 Admin host is convenient but not flexible if you manage several TM1 services.
Each TM1 service might need different settings and you do not necessarily want users to be able to see the development or test services for example.

mytm1.xla is an Excel addin that logs the users on a predefined server and settings as shown on that graph:

With such a setup, you can switch your users from one server to the other without having to tinker the tm1p.ini files on every single desktop.
This solution probably offers the most flexibility and maintainability as you could add conditional statements to point different groups of users to different servers/settings and even manage and retrieve these settings from a cube through the API.

This addin also includes:
- previous code like the "TM1 freeze" button
- it loads automatically an excel spreadsheet named after the user so each user can customise it with their reports/links for a faster access to their data.

The TM1 macro OPTSET, used in the .xla below, can preconfigure the tm1p.ini with a lot more values.

The official TM1 Help does not reference all the available values though.
Here is a more complete list, you can actually change all the parameters displayed in the Server Explorer File->Options with OPTSET:
AdminHost
DataBaseDirectory
IntegratedLogin
ConnectLocalAtStartup
InProcessLocalServer
TM1PostScriptPrinter
HttpProxyServerHost
HttpProxyServerPort
UseHttpProxyServer
HttpConnectorUrl
UseHttpConnector

and more:

AnsiFiles
GenDBRW
NoChangeMessage
DimensionDownloadMaxSize

this also applies to OPTGET

WARNING:
Make sure that all hosts in the AdminHost line are up and working otherwise Architect/Perspectives will hang for a couple of seconds while trying to connect to these hosts.

Locking cubes is a good way to insure your (meta)data is not tampered with.
Right click on the cube you wish to lock, then select Security->Lock.
This now protects the cube contents from TI process and (un)intentional admins' changes.
However, this makes updating your (meta)data more time consuming, as you need to remove the lock prior to updating the cube.

Hopefully, the function CubeLockOverride allows you to automate that step. The following TI code demonstrates this,
.lock a cube
.copy/paste the code in a TI Prolog tab
.change the parameters to fit your system
.execute:

# uncomment / comment the next line to see the process win / fail
CubeLockOverride(1);

Dim = 'Day';
Element = 'Day 01';
Attribute = 'Dates 2010';
NewValue = 'Saint Glinglin';

if( CellIsUpdateable('}ElementAttributes_' | Dim, Element, Attribute) = 1);
    AttrPutS(NewValue, Dim, Element, Attribute);
else;
    ItemReject('could not unlock element ' | Element | ' in ' | Dim);
endif;

Note: CubeLockOverride is in the reserved words listed in the TM1 manual but its function seems to be only documented in the 8.4.5 releases notes.
This works from 8.4.5 to the more recent 9.x series

One day you might face or already faced the problem of too many licences being in use and as a result additional users cannot log in.
Also on a default setup, nothing stops users from opening several tm1web/perspectives sessions and reach the limit of licenses.
So in order to prevent that:

.open the cube }ClientProperties, change all users' MaximumPorts to 1
.in your tm1s.cfg add that line, it will timeout all idle connections after 1 hour:
IdleConnectionTimeOutSeconds = 3600

To see who's logged on:
.use tm1top
or
.open the cube }ClientProperties
all logged users have the STATUS measure set to "ACTIVE"
or
.in server manager (rightclick server icon), click "Select clients..." to get the list

To kick some users without taking the server down:
in server explorer right click on your server icon -> Server Manager
select disconnect clients and "Select clients..."
then OK and they are gone.

Unfortunately there is still no workaround for the admin to log in when users take all the slots allowed.

Changing a rule or process in TM1 does not show up in the logs.
That is fine as long as you are the only Power User able to tinker with these objects.
Unfortunately, it can get out of hand pretty quickly as more power users join the party and make changes that might impact other departments data.
So here goes a simple way to report changes.

The idea is to compare the current files on the production server with a backup from the previous day.

You will need:

• Access to the live TM1 Data Folder
• Access to the last daily backup
• A VB script to email results you can find one there
• diff, egrep and unix2dos
   

Save these files in D:\TM1DATA\BIN for example, or some path accessible to the TM1 server.

In the same folder create a diff.bat file, replace all the TM1DATA paths to your configuration:

@echo off
cd D:\TM1DATA\BIN
del %~1
rem windows file compare fc is just crap, must fallback to the mighty GNU binutils
diff -q "\\liveserver\TM1DATA" "\\backupserver\TM1DATA" | egrep "\.(pro|RUX|xdi|xru|cho)" > %~1
rem make it notepad friendly, i.e. add these horrible useless CR chars at EOL, it's 2oo8 but native windows apps are just as deficient as ever
unix2dos %~1
rem if diff is not empty then email results
if %~z1 GTR 1 sendattach.vbs mailserver 25 from.email to.email "[TM1] daily changes log" " " "D:\TM1DATA\BIN\%~1"

Now you can set a TM1 process with the following line to run diff.bat and schedule it from a chore.

ExecuteCommand('cmd /c D:\TM1DATA\BIN\diff.bat diff.txt',0);

Best is to run the process at close of business, just before creating the backup of the day.

And you should start receiving emails like these:

Files \\liveserver\TM1DATA\Check Dimension CollectionCat.pro and \\backupserver\TM1DATA\Check Dimension CollectionCat.pro differ
Files \\liveserver\TM1DATA\Productivity.RUX and \\backupserver\TM1DATA\Productivity.RUX differ
Only in \\liveserver\TM1DATA: Update Cube Branch Rates.pro

In this case we can see that the rules from the Productivity cube have changed today.

Using the script in the Send Email Attachments article, it is possible to set it up to automatically email the Admin when a process in a chore fails.

Here is how to proceed:

  
1. Setup admin email process
First we create a process to add an email field to the ClientProperties cube and add an email to forward to the Admin.

1.1 create a new process
---- Advanced/Parameters Tab, insert this parameter:
AdminEmail / String / / "Admin Email?"

--- Advanced/Prolog tab
if(DIMIX('}ClientProperties','Email') = 0);
DimensionElementInsert('}ClientProperties','','Email','S');
Endif;

--- Advanced/Epilog tab
CellPutS(AdminEmail,'}ClientProperties','Admin','Email');

1.2 Save and Run

2. Create monitor process

---- Advanced/Prolog tab
MailServer = 'smtp.mycompany.com';
LogDir = '\\tm1server\e$\TM1Data\Log';
ScriptDir = 'E:\TM1Data\';

NumericGlobalVariable( 'ProcessReturnCode');

If(ProcessReturnCode <> ProcessExitNormal());

If(ProcessReturnCode = ProcessExitByChoreQuit());
Status = 'Exit by ChoreQuit';
Endif;
If(ProcessReturnCode = ProcessExitMinorError());
Status = 'Exit with Minor Error';
Endif;
If(ProcessReturnCode = ProcessExitByQuit());
Status = 'Exit by Quit';
Endif;
If(ProcessReturnCode = ProcessExitWithMessage());
Status = 'Exit with Message';
Endif;
If(ProcessReturnCode = ProcessExitSeriousError());
Status = 'Exit with Serious Error';
Endif;
If(ProcessReturnCode = ProcessExitOnInit());
Status = 'Exit on Init';
Endif;
If(ProcessReturnCode = ProcessExitByBreak());
Status = 'Exit by Break';
Endif;

vbody= 'Process failed: '|Status| '. Check '|LogDir;
Email = CellGetS('}ClientProperties','Admin','Email');
If(Email @<> '');
S_Run='cmd /c '|ScriptDir|'\SendMail.vbs '| MailServer |' 25 '|Email|' '|Email|' "TM1 chore alert" "'|vBody|'"';
ExecuteCommand(S_Run,0);
Endif;
Endif;

2.1. adjust the LogDir, MailServer and ScriptDir values to your local settings

3. insert this monitor process in chore
This monitor process needs to be placed after every process that you would like to monitor.

How does it work?
Every process, after execution, returns a global variable "ProcessReturnCode", and that variable can be read by a process running right after in a chore.
The above process checks for that return code and pipes it to the mail script if it happens to be different from the normal exit code.

If you have a lot of processes in your chore, you will probably prefer to use the ExecuteProcess command and the check return code over a loop. That method is explained here.

Following up on monitoring chores by email, we will take a slightly different approach this time.
We use a "metaprocess" to execute all the processes listed in the original chore, check their return status and eventually act on it.
This allows for maximum flexibility as you can get that controlling process to react differently to any exit status of any process.

1. Create process ProcessCheck
--- Data Source tab
choose ASCII, Data Source Name points to an already existing chore file, for example called Daily Update.cho

--- Variables tab
Variables tab has to be that way:

--- Advanced/Data tab

#mind that future TM1 versions might use a different format for .cho files and that might break this script
If(Tag @= '6');

MailServer = 'mail.myserver.com';
LogDir = '\\server\f$\TM1Data\myTM1\Log';

#get the process names from the deactivated chore
Process=Measure;

NumericGlobalVariable( 'ProcessReturnCode');
StringGlobalVariable('Status');

ErrorCode = ExecuteProcess(Process);

If(ErrorCode <> ProcessExitNormal());

If(ProcessReturnCode = ProcessExitByChoreQuit());
Status = 'Exit by ChoreQuit';
#Honour the chore flow so stop here and quit too
ChoreQuit;
Endif;
If(ProcessReturnCode = ProcessExitMinorError());
Status = 'Exit with Minor Error';
Endif;
If(ProcessReturnCode = ProcessExitByQuit());
Status = 'Exit by Quit';
Endif;
If(ProcessReturnCode = ProcessExitWithMessage());
Status = 'Exit with Message';
Endif;
If(ProcessReturnCode = ProcessExitSeriousError());
Status = 'Exit with Serious Error';
Endif;
If(ProcessReturnCode = ProcessExitOnInit());
Status = 'Exit on Init';
Endif;
If(ProcessReturnCode = ProcessExitByBreak());
Status = 'Exit by Break';
Endif;

vbody=Process|' failed: '|Status|'. Check details in '|LogDir;
Email = CellGetS('}ClientProperties','Admin','Email');
If(Email @<> '');
S_Run='cmd /c F:\TM1Data\CDOMail.vbs '| MailServer |' 25 '|Email|' '|Email|' "TM1 chore alert" "'|vBody|'"';
ExecuteCommand(S_Run,0);
Endif;
Endif;

Endif;

The code only differs from the first method when the process returns a ChoreQuit exit. Because we will be running the chore Daily Update from another chore, the ChoreQuit will not apply to the later, so we need to specify it explicitly to respect the flow and stop at the same point.

2. Create chore ProcessCheck
just add the process above and set it to the same frequency and time as the Daily Update chore that you want to monitor

3. Deactivate Daily Update
since the ProcessCheck chore will run the Daily Update chore there is no need to execute Daily Update another time

A quick way to monitor users login/logout on your system is to log the STATUS value (i.e. ACTIVE or blank) from the }ClientProperties cube.

View->Display Control Objects
Cubes -rightclick- Security Assignments
browse down to the }ClientProperties cube and make sure the Logging box is checked
tm1server -rightclick- View Transaction Log
Select Cubes: }ClientProperties

All the transactions are stored in the tm1s.log file, however if you are on a TM1 version prior to version 9.1 and hosted on a Windows server, the file will be locked.
A "Save Data" will close the log file and add a timestamp to its name, so you can start playing with it.

/!\ This trick does not work in TM1 9.1SP3 as it does not update the STATUS value.

TM1 chore scheduling is frequency based, i.e. it will run and try to pull data after a predefined period of time regardless of the availability of the data at the source. Unfortunately it can be a hit or miss and it can even become a maintenance issue when Daylight Saving Time come into play.
Ideally you would need to import or get the data pushed to TM1 as soon as it is available. The following article shows one way of achieving that goal with an iSeries as the source...

prerequesites on the TM1 server:

• Mike Cowie's TIExecute
• iSeries Client Access components (iSeries Access for Windows Remote Command service)

Procedure to follow

1. Drop TM1ChoreExecute, TM1ProcessExecute, associated files and the 32bit TM1 API dlls in a folder on the TM1 server (see readme in the zip for details)
2. Start iSeries Access for Windows Remote Command on the TM1 server, set as automatic and select a user that can execute the TM1ChoreExecute
3. In client access setup: set remote incoming command "run as system" + "generic security"
4. On your iSeries, add the following command after all your queries/extracts:

RUNRMTCMD CMD('start D:\path\to\TM1ChoreExecute AdminServer TM1Server UserID Password ChoreName') RMTLOCNAME('10.xx.x.xx' *IP) WAITTIME(10)
10.xx.x.xx IP of your TM1 server
D:\path\to path where the TM1ChoreExecute is stored
AdminServer name of machine running the Admin Server service on your network.
TM1Server visible name of your TM1 Server (not the machine name of the machine running TM1.
UserID TM1 user ID with credentials to execute the chore.
Password TM1 user ID's password to the TM1 Server.
ChoreName name of requested chore to be run to load data from the iSeries.

You should consider setting a user/pass to restrict access to the iSeries remote service and avoid abuse.
But ideally an equivalent of TM1ChoreExecute should be compiled and executed directly from the iSeries.

A luser just ran that hazardous process or spreading on the production server and as a result trashed loads of data on your beloved server.
You cannot afford to take the server down to get yesterday's backup and they need the data now...
Fear not, the transaction log is here to save the day.

• In server explorer, right click on server->View Transaction Log
• Narrow the query as much as you can to the time/client/cube/measures that you are after
• /!\ Mind the date is in north-american format mm/dd/yyyy
• Edit->Select All
• Edit->Back Out will rollback the selected entries

Alternatively, you could get the most recent backup of the corresponding .cub of the "damaged" cube:

• In server explorer: right-click->unload cube
• Overwrite the .cub with the backed up .cub
• Reload the cube from server explorer by opening any view from it

The Applications folder is great but limited to views and xls files, well not anymore.
The following explains how to make available just any file in your Applications folders.

1. create a file called myfile.blob in }Applications\ on your TM1 server
it should contain the following 3 lines:
ENTRYNAME=tutorial.pdf
ENTRYTYPE=blob
ENTRYREFERENCE=TM!:///blob/public/.\}Externals\tutorial.pdf

2. place your file, tutorial.pdf in this case, in }Externals or whatever path you defined in ENTRYREFERENCE

3. restart your TM1 service

ENTRYNAME is the name that will be displayed in Server Explorer.
ENTRYREFERENCE is the path to your actual file. The file does not need to be in the folder }Externals but the server must be able to access it

/!\ avoid large files, there is no sign to tell you to wait while loading, impatient users might click several times on the file and unvoluntarily flood the server or themselves.
/!\ add the extension in ENTRYNAME to avoid confusion, although it is not a .xls file, it will be displayed with an XLS icon.

Beyond the purely ludic and mathematical aspects of sudoku, this code demonstrates how to set up dimensions, cubes, views, cell formating, security at elements and cells levels all through Turbo Integrator in just one process.

Thanks to this application, you can demonstrate your TM1 ROI: none of your company employees will need to shell out £1 ever again for their daily sudoku from the Times.
Alternatively, you could move your users to a "probation" group before they start their shift. It is only by completing successfully the sudoku that the users will be moved back to their original group.
This way you can insure your company employees are mentally fit to carry out changes to the budget, especially after last evening ethylic abuses down the pub.

Of course it exists many sudoku available for Excel, this is one is to be played primarily from the cube viewer, but you could also slice the view and play it from Excel too.

How to install:
.Save the processes Create Sudoku.pro and Check Sudoku.pro  in your TM1 folder and reload your server or copy the code directly to new turbo integrator processes.
.Execute "Create Sudoku". That creates the cube, default view and new puzzle in less than a second.

The user can input numbers in the "input" grid only where there are zeroes. The "solution" grid cannot be read by default.
.Execute "Check Sudoku" to verify your input grid matches the solution.
If you are logged under an admin account, you will not see any cells locked, you need to be under the group defined in the process to see the cells properly locked.

You might want to change the default group allowed to play and the number of initial pairs that are blanked in order to increase difficulty.

The algorithm provided to generate the sudoku could be quickly modified to solve by brute force any sudoku. Provided the sudoku grid is valid, it will find the solution, however some sudokus with too many empty cells will have more than one solution.

removing a TM1 service
in a DOS shell:
go to the \bin folder where TM1 is installed then:
tm1sd -remove -n "TM1 Service"
where "TM1 Service is the name of an existing TM1 service
or: sc delete "TM1 Service"

removing the TM1 Admin services
sc delete tm1admsdx64
sc delete TM1ExcelService

installing a TM1 service
in a DOS shell:
go to the \bin folder where TM1 is installed then:
tm1sd -install -n "TM1 Service" -z DIRCONFIG
where DIRCONFIG is the absolute path where the tm1s.cfg of your TM1 Service is stored

manually starting a TM1 service
from a DOS shell in the \bin folder of the TM1 installation:
tm1s -z DIRCONFIG

remotely start a TM1 service
sc \\TM1server start "TM1 service"

remotely stop a TM1 service
sc \\TM1server stop "TM1 service"

TM1Top provides realtime monitoring of your TM1 server, pretty much like the GNU top command.

It is bundled with TM1 only from version 9.1. You might have to ask your support contact to get it or get Ben Hill's TM1Top below.

. Dump the files in a folder
. Edit tm1top.ini, replace myserver and myadminhost with your setup

servername=myserver
adminhost=myadminhost
refresh=5
logfile=C:\tm1top.log
logperiod=0
logappend=T

. Run the tm1top.exe

Commands:
X exit
W write display to a file
H help
V verify/login to allow cancelling jobs
C cancel threads, you must first login to use that command
Keep in mind all it does is to insert a "ProcessQuit" command in the chosen thread.
Hence it will not work if the user is calculating a large view or a TI is stuck in a loop where it never reads the next data record, as the quit command is entered for the next data line rather than the next line of code. Then your only option becomes to terminate the user's connection with the server manager or API. (thanks Steve Vincent).

Ben "Kyro" Hill did a great job developing a very convenient GUI TM1Top.

TL;DR Skip directly to the bottom of the article to find out the fastest and most secure SSL configuration for WLP/TM1Web. Otherwise, read on to understand the how and the why. 

TM1Web also known as "Planning Analytics Spreadsheet Services" is a web app serving websheets through the IBM WebSphere Liberty Profile webserver currently operating under Java Running Environment 1.8.0. 

The encryption to communicate with that WLP server is handled by a choice of ciphersuites to be configured in <TM1Web_install>\wlp\usr\webserver\server.xml 

One line of particular interest regarding security and compliance is the following setting the enabled ciphers:

<ssl id="CAM" keyStoreRef="CAMEncKeyStore" serverkeyAlias="encryption" enabledciphers="SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 SSL_ECDHE_ECDSA_WITH_AES_256 GCM_SHA384" sslProtocol="TLSv1.2"/>

However, the IBM documentation fails to provide the list of available ciphersuites. If you are familiar with ciphersuites, it should be an easy guess after a few online searches. But you can also unveil the exact list of cipher suites by compiling and running the linked Ciphers.java code.

javac Ciphers.java
java Ciphers

I will spare you all the work of finding, downloading, installing the correct java compiler, compiling the code and finally executing it. So, here is the list of all the ciphersuites available for TM1Web. The recommended ciphersuites are set in bold.

TLS v1.2

• SSL_DHE_DSS_WITH_AES_128_CBC_SHA
• SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
• SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
• SSL_DHE_DSS_WITH_AES_256_CBC_SHA
• SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
• SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 
• SSL_DHE_RSA_WITH_AES_128_CBC_SHA 
• SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 
• SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 
• SSL_DHE_RSA_WITH_AES_256_CBC_SHA 
• SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 
• SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
• SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
• SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA 
• SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA 
• SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA 
• SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
• SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 
• SSL_ECDH_RSA_WITH_AES_128_CBC_SHA 
• SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 
• SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 
• SSL_ECDH_RSA_WITH_AES_256_CBC_SHA 
• SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 
• SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 
• SSL_RSA_WITH_AES_128_CBC_SHA 
• SSL_RSA_WITH_AES_128_CBC_SHA256 
• SSL_RSA_WITH_AES_128_GCM_SHA256 
• SSL_RSA_WITH_AES_256_CBC_SHA 
• SSL_RSA_WITH_AES_256_CBC_SHA256 
• SSL_RSA_WITH_AES_256_GCM_SHA384 

TLS v1.3

• TLS_AES_128_GCM_SHA256 
• TLS_AES_256_GCM_SHA384 
• TLS_CHACHA20_POLY1305_SHA256 
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

So what does this all mean? A ciphersuite is a combination of algorithms used in the SSL/TLS protocol for secure communication. Each ciphersuite name is structured to describe the algorithmic contents of it.

For example, the ciphersuite `SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` is built with the following components:

• SSL: This indicates the protocol version. In this case, it's TLS v1.2 (Transport Layer Security). 
• ECDHE: This stands for Elliptic Curve Diffie-Hellman Ephemeral. It's the key exchange method used in this ciphersuite. Diffie-Hellman key exchanges which use ephemeral (generated per session) keys provide forward secrecy, meaning that the session cannot be decrypted after the fact, even if the server's private key is known. Elliptic curve cryptography provides equivalent strength to traditional public-key cryptography while requiring smaller key sizes, which can improve performance.
• ECDSA: This stands for Elliptic Curve Digital Signature Algorithm. It's the algorithm used for server authentication. The server's certificate must contain an ECDSA-capable public key.
• AES_256: This indicates the symmetric encryption cipher used. In this case, it's AES (Advanced Encryption Standard) with 256-bit keys. This is reasonably fast and not broken.
• GCM: This stands for Galois/Counter Mode. It's a mode of operation for symmetric key cryptographic block ciphers. It's used here for the symmetric encryption cipher.
• SHA384: This is the hash function used. It's used for the Message Authentication Code (MAC) feature of the TLS ciphersuite. This is what guarantees that each message has not been tampered with in transit. SHA384 is a great choice.

Some ciphersuites in the list above are not recommended because of the following obsolete algorithms:

• DHE_DSS: This is an old key exchange algorithm that uses the Diffie-Hellman key exchange and the DSS (Digital Signature Standard) algorithm for digital signatures. It's not recommended for use because DSS is considered less secure than ECDSA (Elliptic Curve Digital Signature Algorithm), and Diffie-Hellman is not as efficient as Elliptic Curve Diffie-Hellman.
• RSA as server authentication: While RSA is still widely used, it's not recommended for use as both the key exchange and authentication algorithm. This is because it does not provide Perfect Forward Secrecy.
• CBC: This is a mode of operation for symmetric key cryptographic block ciphers. It's not recommended for use because it's vulnerable to padding oracle attacks, which allow an attacker to decrypt ciphertext without knowing the encryption key. Instead, it's recommended to use GCM (Galois/Counter Mode) or CCM (Counter with CBC-MAC).
•  SHA (also known as SHA1): This is a hash function that is not recommended for use because it's considered to be weak and vulnerable to collision attacks. Instead, it's recommended to use SHA-256 or SHA-384.

faster and more secure TM1Web with TLS v1.3

TLS 1.3 offers several performance improvements over TLS 1.2. One of the key differences is the faster TLS handshake. Under TLS 1.2, the initial handshake was carried out in clear text, requiring encryption and decryption, which added considerable overhead to the connection. TLS 1.3, on the other hand, adopted server certificate encryption by default, which reduced this overhead and allowed for faster, more responsive connections. 

Another performance improvement in TLS 1.3 is the Zero Round-Trip Time (0-RTT) feature. This feature eliminates an entire round-trip on the handshake, saving time and improving overall site performance. When accessing a site that has been visited previously, a client can send data on the first message to the server by leveraging pre-shared keys (PSK) from the prior session.

TLS 1.3 offers more robust security features compared to TLS 1.2. It supports cipher suites that do not include key exchange and signature algorithms, which are used in TLS 1.2. TLS 1.2 used ciphers with cryptographic weaknesses that had security vulnerabilities. TLS 1.3 also eliminates the security risk posed by a static key, which can compromise security if accessed illicitly. Furthermore, TLS 1.3 uses the Diffie-Hellman Ephemeral algorithm for key exchange, which generates a unique session key for every new session. This session key is one-time and is discarded at the end of every session, enhancing forward secrecy.

So, an optimal configuration for WLP server.xml will be: 

<ssl id="CAM" keyStoreRef="CAMEncKeyStore" serverkeyAlias="encryption" enabledciphers="TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256" sslProtocol="TLSv1.3">

Unfortunately, I haven't found a way to have both TLSv1.2 and TLSv1.3 protocols available at the same time in that configuration file. If you know how, please leave a comment with the details.

You can easily check the configuration is correct in Chrome, with Developer Tools -> Security -> Security Overview -> Connection: "The connection to this site is encrypted and authenticated using TLS 1.3"

On a side note, the configuration file for TM1Web is located at <TM1Web_install>\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml.

The number of parameters in the tm1s.cfg has been steadily rising as more features have been made available over the years in TM1. So, a cheatsheet summarising all these parameters can help as an overview of the different settings that a TM1 server can be configured with.

This cheatsheet is now available in the following formats:

• csv so you can build your own variations of the cheatsheet
• tm1s.cfg including all parameters, only the required parameters are uncommented, every parameter is set to its known default value (as of 2023-02-14 and according to the IBM online documentation). There should not be a need to explicitly define a parameter when you just want to stick to the default value. However, be cautious that IBM may change default values and that could lead to issues when upgrading versions.
• md markdown to save in your personal knowledge management repository full of markdown files to ripgrep through fzf.vim
• pdf for an allegedly pretty overview (coming soon)
• html below or here on its own that you can "Save as" to use as a local copy.

The cheatsheet is generated with python scripts (coming soon) responsible for the conversion of the csv file to a pandas dataframe and then exported to different formats. The csv file currently holds the following fields:

1. parameter: name of the parameter
2. optional: indicates if the parameter is either required or optional.
3. restart: indicates if the parameter is either dynamic or static 🔄, in the later case, it requires a service restart when its value has been modified
4. url: URL address of the official IBM Planning Analytics documentation for that parameter
5. default: default value of that parameter when it is not explicitly declared
6. type: type of that parameter (bool, int, float, str, time). This will be useful for scripts checking tm1s.cfg validity
7. context: arbitrary categorisation for the context of the parameter e.g. it can be Network related, Rules related, etc..
8. dependency: that may hold the name of another parameter that the current parameter may rely on to operate
9. description: short description about what the parameter does

The categorisation is completely arbitrary, most parameters could fit in several categories, so I just picked one that seemed most appropriate. This is a limitation and probably something to look into for the design of future versions of that csv file.

And finally, the tm1s.cfg parameters cheatsheet in html.

Note that there is a drop down menu at the top of the Context column. This allows you to show only parameters that relate to a specific aspect of your TM1 server. If you are on mobile, you probably need to rotate your screen for a wide display in order to display all 5 columns.

tm1s.cfg parameters cheatsheet

parameters in bold are required.
🔄 = static parameter, the TM1 service must be restarted for the new value of that parameter to take effect.