HowTo: Come migliorare la compatibilità dei meeting Domino verso gli altri sistemi di posta

Nei giorni scorsi mi è capitato di avere problemi con i meeting inviati da utenti Domino perchè quando venivano ricevuti da utenti  exchange o gmail non generavano la risposta di accettazione  non permettendo quindi all'organizzatore di avere il quadro completo delle accettazioni.

Ad esempio quando veniva generato un meeting veniva ricevuto da gmail in questa forma

Il ricevente può aggiungere il meeting al calendario tramite il bottone "Add to Google calendar" ma non viene generata la mail di ritorno per l'organizzatore.

La soluzione al problema si può trovare in 2 vie, tramite policy setting Mail oppure tramite  notes.ini con il parametro $CSCompatibilityMode (anche qui ovviamente tramite setting Desktop potete distribuirlo su tutti i client).

Questo parametro attivabile da 8.5 in poi su client o server permette di inviare meeting è client/server in modalità di compatibilità.

Le opzioni del parametro  possibili sono le seguenti

• 0 - Option is hidden and off for all meetings created on that client.
• 1 - Option is hidden and defaults to on for all meetings created on that client. The chair cannot see the option nor make any changes to it.
• 2 - Option is displayed and defaults to off for all meetings created on that client. The meeting chair can use the option to set whether it is on or off for each meeting created. The chair can also update the selection later to turn the option on or off at that time.
• 3 - Option is displayed but is locked on for all meetings.

Dopo aver valorizzato il parametro nel notes.ini con uno dei 3 valori sovrastanti potrete vedere una nuova voce nei meeting che informa Notes sull'invio in modalità di compatibilità.

A questo punto dopo aver messo la spunta ho inviato u nmeeting da Notes ed il risultato è stato corretto: ora l'utente ricevente ha a disposizione le opzioni di risposta che generano il ritorno verso Domino quindi l'organizzatore può avere sotto controllo la riunione.

Si può impostare tutto tramite setting di mail , dove però non si può replicare l'effetto di $CSCompatibilityMode=3 , ovvero presente visibile e spuntato di default. 

Da setting mail però si possono però programmare le cose differenziando per domain e tipo di client:

Qui il default è Disable compatibilty mode , se impostate l'ozione Detect compatibilty mode come in figura potete andare tramite i 2 tab successivi ad  impostare una tabella definendo dominio di posta e sistema di posta usato:

qui imposto msbiro.net come dominio Google Mail

nel tab client settings si vedono i settaggi impostati da domino per ogni tipo di sistema di posta

Ovviamente la scelta delle policy è quella che garantisce una migliore compatibilità verso tutti i sistemi di posta perchè prevede settaggi personalizzati in base al tipo posta del dominio ricevente ma ovviamente ha il grosso onere di dover essere gestita manualmente caso per caso.

Al momento mandando inviti con l'opzione di compatibiltà non ho trovato contro indicazioni. I meeting in teoria con maggiori problemi di compatibilità sono i ripetitivi  ma l'esempio che vi ho messo sopra verso Gmail è stato preso da un meeting singolo.

Il settaggio se lo mettete da notes.ini va messo client e server. 

In caso siate in ambiente ibrido Connections Cloud le invitation invitate da iNotes o Verse vengono già inviate correttamente quindi dovete concentrarvi solo sui client Notes.

Qui un documento del wiki di Domino che parla della compatibilità  e qui  un documento IBM con alcuni screenshot sul client detection mapping ed in questa pagina viene descritto il parametro $CSCcompatibiltyMode.

IBM Connections how to: aumentare la dimensione massima dei files caricati

In IBM Connections 5 la dimensione massima impostata sull'upload dei files è di 500MB.

Se avete necessità di aumentarla potete procedere seguendo i seguenti step:

Apertura di un prompt wsadmin

Tramite il comando seguente inizializzate l'amministrazione files

execfile("filesAdmin.py")    

Ora è necessario eseguire il checkout della configurazione files:

(/opt/ibm/DEVEL è il path di lavoro di esempio e nomeCella01 è il nome della vostra cella di Connections)

FilesConfigService.checkOutConfig("/opt/ibm/DEVEL", "nomeCella01")

Con il comando seguente impostiamo la dimensione massima a 1GB

FilesConfigService.updateConfig("file.media.maximumSizeInKb", "1048576") 

Ora eseguiamo il check in della configurazione

FilesConfigService.checkInConfig("/opt/ibm/DEVEL", "nomeCella01")

Per sincronizzare i nodi di Connections possiamo usare il comando seguente

synchAllNodes()

Per verificare il valore impostato dei files, possiamo usare questo comando (funziona dopo aver inizializzato amministrazione ed eseguito il checkout della conf)

FilesConfigService.showConfig()

Se aumentate la dimension massima dei files caricabili probabilmente poi vorrete anche aumentare la dimensione delle personal library, con il comando seguente la portate a 2GB

FilesPolicyService.editPersonalDefault(2147483648L)

Per essere sicuri che la modifica venga recepita dai client degli utenti, dovete forzare il clear della cache dei browser incrementando il valore del version stamp.

Nelle raccomandazioni sulle dimensioni IBM raccomanda di non andare oltre i 2GB per singolo file. Se espandete le dimensioni dei file ricordatevi anche di configurare HTTP e WAS per permettere agli utenti di poterli scaricare agevolmente.

Domino HowTo: come calcolare il numero di mailbox corrette e come configurare SMTP con relay o failover su più host

In questi giorni mi sono imbattuto in alcune configurazioni che per quanto basilari  non sono note ad alcuni dei colleghi Admin, quindi ve le riassumo in questo post.

Calcolare il numero di mailbox

Innanzi tutto una regola generale: se il vostro server Domino è un server di posta mettete 2 mailbox.

Per sapere se necessitate di ulteriori mailbox esiste una formula matematica.

Dovete andare in console Domino e dare il seguente comando

show stat mail

fra i vari dati estratti vi interessano i seguenti 2 (a dx le loro descrizioni)

Mail.Mailbox.Accesses	Total number of times that threads accessed any mailbox on the server.
Mail.Mailbox.AccessConflicts	The number of times that a thread attempting to access a mailbox had to wait because the number of concurrent threads exceeded the number of mailboxes configured. For example, if there are three mailboxes configured, and there are four concurrent accesses, the conflict count would be incremented. If the number of access conflicts consistently exceeds two percent of the value of Mail.Mailbox.Accesses, consider creating an additional mailbox.

Ora usate i 2 valori per effettuare il calcolo :

(Mail.Mailbox.AccessConflicts / Mail.Mailbox.Accesses) x 100

Se il risultato ottenuto è > 2 dovete aggiungere una mailbox al vostro server.

Come regola il numero massimo di mailbox solitamente richieste arriva ad un massimo di 4.

Qui potete trovare una technote con tutti i dettagli del caso.

SMTP Mail relay - Load Balancing / Fail Over

Se utilizzate un mail relay SMTP , dovete impostarlo nel documento di configurazione dei server nel tab Router/SMTP --> Basics alla voce Relay host for messages leaving the local internet domain.

Qui se avete pù di un relay potete separarli da una virgola o da punto e virgola

[10.1.2.3],[10.1.2.4]   in questo caso ci sarà load balancing fra i 2 relay (accesso random)

[10.1.2.3];[10.1.2.4]   in questo caso ci sarà failover fra i 2 (prima il primo , poi il secondo)

In questo caso il riferimento potete trovarlo in queste slides

Come risolvere problemi di sincronia Traveler con dispositivi Apple o Android

E' un pò di tempo che mi arrivano alcune richieste di aiuto su problemi di sincronizzazione di dispositivi con server Traveler, quindi posto qui un pò di comandi che usualmente mi permettono di risolvere il problema.

Il problema tipico è la mancanza di sync nella Inbox (usualmente su dispositivi Apple) o la mancanza totale di alcune cartelle (usualmente dispositivi Android).

Tipicamente procedo in questo modo

tell traveler show Nome Cognome

il server risponde fornendo il Device ID dei dispositivi dell'utente ad esempio : ApplCXXXXXXXXXXX

ora che abbiamo il device ID possiamo eseguire le operazioni

tell traveler reset ApplCXXXXXXXXXXX Nome Cognome 

esegue un reset dei puntatori di sync nel db di Traveler, forzando quindi un resync del dispositivo (attenzione sync di posta / contatto / calendario, quindi da eseguire in accordo con l'utente perchè potrebbe durare alcuni minuti in caso ad esempio di alcune centinaia di contatti)

Se il problema persiste si può provare a rimuovere l´account dal sispositivo Apple , o disinstallare APP Android , poi sul server (il device id , può essere sostituito da * per comodità se l´utente ha 1 dispositivo)

tell traveler security delete ApplCXXXXXXXXXXX Nome Cognome 

tell traveler delete ApplCXXXXXXXXXXX Nome Cognome

Dopo questa operazione rimettiamo il profilo o l'app.

In caso che il problema persista  (avevo una inbox che non si sincronizzava con dispositivo Apple) il problema è molto probabilmente sul db utente (anche se in apparenza sembra tutto normale).

In questo caso ho risolto con un

load compact mail\nomecognome.nsf -REPLICA  

How to: Distribuzione Notes 9.0 IFR2

In questi giorni IBM ha rilasciato IFR2 per Notes 9, che comprende diverse fix di sicurezza che potete trovare elencate nella technote che annuncia il rilascio.

Oltre alla classica installazione manuale, possiamo ricorrere agli update site, se vogliamo installare in automatico questa IF2 ai client dei nostri utenti o anche semplicemente metterla a loro disposizione fra i Widgets.

Quello che ci serve sono

• un db di update site
• la fix scaricata
• 15 minuti di tempo

Dopo aver scaricato la fix , invece di lanciare l'eseguibile e fare l'installazione manuale scompattatela, al suo interno troveremo i seguenti file e cartelle.

Abbandoniamo la fix, apriamo il db di Update Site che abbiamo sul nostro server domino (qui info al riguardo) ed andiamo ad importare la fix cliccando sul bottone Import Local Update Site e selezionando il file site.xml

Attendiamo qualche minuto perchè il db importi e firmi i file

all'interno del update site avremo tutte le feature installate

Ora andriamo in Actions -> Show URLs

e copiamo uno dei 2 link a seconda del protocollo che vogliamo utilizzare per creare il widget

da un client Notes, andiamo a configurare un Widget , selezionando come da screen sottostante

Adesso ci verrà richiesto dove trovare l'update site, incolliamo il link ottenuto in precedenza e selezioniamo tutte le features presenti ed andiamo avanti.

A questo punto il più è fatto, e sul Notes dove state eseguendo l'operazione verrà installato il Widget che vi installerà IFR2, chiedendo un riavvio di Notes al suo termine.

Ora per rendere disponibile il Widget ai colleghi per una installazione manuale dovete pubblicarlo nel catalogo dei Widget, cliccandoci su con il bottone destro e selezionando "publish to catalog"

Compiliamo almeno il campo Title, poi save and close.

Ora che il Widget è a disposizione, se lo andrete ad inserire in una categoria impostata per il deploy automatico tramite una Desktop Policy il deploy del widget inizierà automaticamente sui client, altrimenti dovrà essere installato manualmente (opzione da valutare in caso di client sparsi geograficamente o di trasfertisti).

Questa semplice procedura la potete usare anche per distribuire feature aggiuntive a Notes come un dizionario.

Update: Aggiornato il modo di ottenere URL con un metodo più agevole, thanks Ralf Petter !

English Version of This Article