In caso non l’aveste notato (sono ovviamente sarcastico) il mondo della produttività office non è più un esclusivo monopolio di Microsoft.  E questo è tanto più vero se ci si sofferma ad analizzare gli strumenti per la comunicazione ed in particolare la messaggistica via e-mail.

Nelle nostre attività di business siamo totalmente condizionati dalla disponibilità ubiqua delle e-mail nonostante il loro trasporto sia basato su una tecnologia di protocollo praticamente “preistorica”. Molti strumenti di instant-messaging cercano in ogni modo di soppiantare la cara vecchia e-mail, ma, anche se concettualmente possono assolvere egregiamente al compito di contatto continuo nei gruppi di lavoro, sono ancora troppo avvolti da un’aura di “gioco” o, peggio, di “fancazzismo” che male si accoppia ad un concetto di professionalità e di ordine. Perfino in mobilità i più moderni device portatili, siano essi tablet, smartphone o “semplici” telefoni, pur infarciti di tutti i possibili strumenti per comunicare in modalità “chat”, non si azzardano nemmeno ad uscire sul mercato senza un adeguato supporto per la posta elettronica.

Già, perchè nel mondo del lavoro la posta elettronica è ancora dominatrice incontrastata. E’ flessibile, non ha virtualmente limiti, è intuitiva e, qui arriva il bello, seppure non progettata per questo scopo, si è adattata nel tempo ed in modo improprio al document-workflow. Le sue capacità di trasporto di oggetti allegati, unite alla pigrizia mentale dei suoi utilizzatori che sono sempre poco inclini al cambiamento oltre che, purtroppo, alla loro ignoranza di fronte ad un computer, hanno fatto che si che, specialmente nelle aziende, la comunicazione via e-mail sia il perno su cui tutta l’attività si regge. Se manca la posta elettronica l’azienda si ferma … tragedia !!! Perfino nelle piccole, piccolissime realtà (meno di 10 postazioni in rete locale) condividere i documenti via e-mail, anzichè tramite cartelle condivise, è pratica consolidata e quasi impossibile da scalzare. Inutile disquisire su quali e quanti problemi questa tecnica possa portare : enorme dispendio di spazio con copie e copie dei medesimi documenti che vanno e vengono, impossibilità di avere controlli di versione coerenti, lamentele sui limiti di spazio alle caselle sulle quali sempre più frustrati it-manager cercano di porre dei limiti, pretesa di poter tenere archiviati i messaggi di posta elettronica dall’inizio dei tempi ecc. ecc.

In questo contesto e nell’ambito di una sempre crescente necessità di razionalizzazione dei costi, le aziende rivolgono una, parimenti, crescente attenzione a soluzioni “cloud” anche e soprattutto per la gestione dei servizi connessi alla posta elettronica: mondo nel quale i due player di maggior riferimento sono Google, con le sue Apps, e Microsoft con Office365 e nello specifico Outlook.com.

L’immaginario collettivo pretende di credere che la semplice esternalizzazione dei servizi di posta elettronica ad un provider nella nuvola possa far magicamente sparire odiosi ed apparentemente improduttivi costi legati a server, spazio, copie e supporto specialistico per “far-funzionare-il-server” (quei loschi figuri che girano in azienda che fanno cose che nessuno capisce ma che si beccano tutti i sacramenti della direzione quando il manager tal-dei-tali non riceve la posta sul suo nuovissimo iTelefono-che-fa-tutto). In realtà molti aspetti operativi non vengono assolutamente considerati o maliziosamente sottovalutati. Ecco, invece, a cosa dovete pensare se state pensando di passare a Google Apps for Business per la gestione della posta elettronica nella vostra piccola o grande azienda.

On-line e Off-line

Se la disponibilità, all’interno di una rete LAN, di un servizio locale è indipendente dalla stabilità e disponibilità di connessione al web, non appena si passa ai servizi nella nuvola questa opzione cade. Miseramente. Un banale disservizio di poche ore del vostro carrier di connettività vi taglia letteralmente fuori, non solo dal mondo esterno, ma anche dalla comunicazione intra aziendale. Non potendo raggiungere il servizio esterno di consegna e recapito della posta elettronica, non posso comunicare con soggetti esterni alla struttura e nemmeno con il vicino di tavolo.

Document Workflow

Usare la posta elettronica per questa attività è concettualmente sbagliato: mandare decine di allegati da distribuire in azienda è una bestemmia informatica. Tuttavia si fà e l’abitudine è dura a morire. Quindi bisogna gestirlo. E come funziona con i servizi cloud ? Pessimamente. Per rendere l’idea è utile un piccolo esempio. Supponiamo che voi siate in una stanza in cui lavorate voi ed un vostro collega, proprio due tavoli uno accanto all’altro. Dovendo consegnare un fascicolo al vostro collega che fareste ? Chiamereste la Dhl per prenotare una consegna, aspettereste che arrivasse il fattorino, prendesse la consegna, la portasse al loro deposito di smistamento, avvisasse il vostro collega che c’è una consegna per lui, arrivasse il giorno dopo con il pacco e lo consegnasse al vostro collega ? Oppure allunghereste il plico da un tavolo all’altro con il semplice gesto di una mano ? Ecco con il document-workflow via e-mail nel cloud succede proprio … la prima opzione. Dal vostro pc, impegnate la banda in output per inviare il documento ad un server esterno, che lo recapita nella mailbox di destinazione del vostro collega (che vi ricordo è seduto accanto a voi) il quale per scaricarlo sul suo computer dovrà impegnare nuovamente la banda in ingresso aziendale per ottenere un documento che, a logica, non avrebbe dovuto nemmeno uscire.

Fat-Client vs. Thin Client

Il cambiamento nella modalità di gestione della posta elettronica avviene troppo spesso basandosi su decisioni sbagliate. La prima su tutte è “Che server adottiamo ?” oppure “Che servizio adottiamo ?“. In realtà l’unica domanda a cui davvero si dovrebbe dare peso è : “Quale è il client di posta che utilizzano e a cui sono abituati i dipendenti ? Se glielo cambiamo quali sono i costi in termini di perdita di produttività ? E di addestramento ?“. Piaccia o no Outlook la fa ancora da padrone e una qualsiasi decisione presa alla leggera che comporti la sua abolizione porta spesso a risultati imprevedibili e a piccole sommosse popolari. In azienda poi pensare di sostituire un client di posta con uno basato su interfaccia web è un errore madornale. In primo luogo perchè l’integrazione del client di posta nella shell del computer è parecchio ostica: in altre, volgari e semplicistiche parole, disporre del vecchio click-destro-invia-a-destinatario-di-posta-elettronica è cosa impossibile senza l’installazione di add-on specifici e, purtroppo, non sempre efficaci. Vi è poi da considerare l’interfaccia stessa. Gmail, anche nella versione business, è identico al “normale” Gmail gratuito per uso privato. L’unica differenza sta nel fatto che se paghi non ti sorbisci la pubblicità. I team di sviluppo di Google non sono mai riusciti a dare coerenza e semplicità ai loro strumenti tant’è che tenere sott’occhio account diversi, impersonare identità diverse, accedere a cartelle di posta secondo criteri privilegiati è operazione per pochi e skillatissimi eletti. Ma andando nello specifico dell’operatività “normale” di posta elettronica la loro interfaccia è decisamente disorganizzata, a volte illeggibile e irrazionale. La fisica e comprensibile suddivisione della mia casella in cartelle è stata soppiantata dalle etichette, componendo un nuovo messaggio DEVO iniziare a digitare il nome del destinatario (sempre che lo abbia in rubrica contatti o lo abbia già utilizzato almeno una volta) per avere dei suggerimenti dal momento che il pop-up della rubrica non mi permette di navigarla secondo mio piacimento (magari ordinando per nome di azienda). L’impostazione di default di ordinamento dei messaggi (per thread) è controintuiva e, ovviamente, scordatevi di lavorare off-line. Ma c’è di più: avendo un allegato corposo da inviare dovrete attendere che sia completato l’upload prima di poter inviare il messaggio, mentre con un fat client, il lavoro di upload viene fatto in background dopo che avete cliccato su Invia.

E non pensate di adottare con leggerezza nemmeno l’Outlook Connector perchè non vi avvicinereste nemmeno lontanamente alle funzionalità offerte dall’accoppiata Outlook Exchange. Piuttosto optate per Thunderbird come client in modalità IMAP e Lightning per collegarvi al calendario. Avrete un simulacro abbastanza soddisfacente di quello che facevate con Outlook.

Warning supremo. Non fate mai l’errore di adottare il servizio Gmail pensando di connettere Outlook (o altro client) in modalità POP3. Scaricando in POP3 non avrete mai evidenza di cosa è finito nella cartella di Gmail dedicata alla posta indesiderata (SPAM) e rischiate di perdere mail molto importanti che magari vi arrivano da nuovi potenziali clienti.

Abbandonare Exchange ?

Per molti l’opzione di abbandonare Exchange è allettante. Non condivido molte delle ostilità gratuite che avversano quel prodotto se non una: in effetti costa parecchio. Tuttavia se utilizzate peculiarità di Exchange come, ad esempio, cartelle pubbliche con proprio indirizzo email, funzionalità di Single Sign On ecc. preparatevi a rinunciarvi o ad inventare accrocchi complicatissimi per poter lavorare nello stesso modo nella nuvola. Più facile pensare a software server alternativi ma sempre in-house.

Lock in

Rimanere intrappolati in una scelta che magari non vi soddisfa è molto facile. L’esuberante offerta di spazio per casella offerto da Gmail porta a considerare con leggerezza il clean-up periodico delle caselle di posta (particolarmente difficile con Gmail) e il moving-away può essere un problema. Se non vi trovate bene dovrete pianificare per tempo spostamenti mastodontici di terabyte di posta qualora le vostre esigenze siano per centinaia di utenti. E tornare ad un servizio in-house potrebbe non essere facile.

Lock Out

L’accesso ad un servizio cloud prevede ovviamente un corrispettivo periodico. Se per contingenze sfortunate doveste trovarvi nella necessità di chiedere al fornitore un posticipo delle scadenze non pensate di trovare in un gestore che ha 350 milioni di utenze attivate un interlocutore amichevole. No paghi ? No posta. Con inevitabili ripercussioni sulle attività dovute all’impossibilità di comunicare con la posta elettronica con clienti e fornitori.

Il Cloud

La c.d. nuvola non è solo “internet”. E’ un concetto di astrazione del “ferro” (un computer/server fisico) dal “servizio” o “i servizi” che questo eroga. Posso avere un cloud anche in casa se già dispongo di un dipartimento IT che sa fare il suo mestiere, con l’indubbio vantaggio che investimenti in impianti e tecnologia possono essere capitalizzati a favore di un aumento del valore dell’azienda: al contrario il mero pagamento di un canone di servizio è un costo che nel momento in cui viene sospeso si “porta via” anche il servizio associato. Una attenta valutazione nel medio periodo di costi annui rispetto agli ammortamenti di un nuovo investimento sono da considerare sempre con grande attenzione.

Come è noto Scalix offre un connettore per Outlook che funziona quale strato di emulazione MAPI: in parole povere Outlook funziona connesso a Scalix come se dietro ci fosse Exchange. Tra le caratteristiche salienti di questo connettore vi è la possibilità di implementare un sistema di SSO (Single Sign On) ovvero quella tecnica per la quale, all’apertura di Outlook, l’utente non dovrà inserire alcuna password nè vi sarà necessità di memorizzarne una nel profilo. In questo modo le policy di scadenza delle password di Windows potranno essere tranquillamente mantenute e l’autenticazione a Scalix avverrà tramite scambio di gettoni (token) Kerberos.

La parte propedeutica alla attivazione del sistema SSO prevede la configurazione di agreement di sincronizzazione con Active Directory (ovviamente dovete avere un Dominio AD configurato) tramite il quale Scalix “carica” e mantiene aggiornati gli utenti secondo quanto specificato in AD. Questa parte non è argomento di questo post.

Quello di cui mi voglio occupare invece è la parte in cui la documentazione Scalix richiede la creazione di un account speciale “scalix-ual” che serve per lo scambio dei messaggi Kerberos tra il server Scalix ed il server Windows. La procedura prevede la creazione, appunto, di un normale account utente chiamato scalix-ual (potrebbe anche essere un altro nome ma bisognerebbe spippolare poi nella configurazione di Scalix per cambiare il principal name), assegnargli una password, generare un file keytab tramite i Support Tools di Windows, ed importare il keytab generato nel database del server Scalix. (Scalix Setup and Administration Guide 11.3 pagina 54 e successive).

La procedura è corretta … tranne in un caso : ovvero quando avete configurato Samba sul vostro server Scalix e avete fatto il join al dominio di Windows.

In questo secondo scenario, infatti, la procedura con cui Samba si aggancia al dominio prevede la creazione di un account per il computer nel container Computer di AD e contestualmente genera anche un database keytab per Kerberos. Se, essendo in questa situazione, seguite la procedura indicata da Scalix per l’implementazione del Kerberos SSO vi troverete con :

• Diversi errori nel log degli eventi del server Windows (sezione Sistema) con ID Evento 11 e origine KDC. Il messaggio (in inglese) recita così : There are multiple accounts with name scalix-ual/HOST.FQDN of type DS_SERVICE_PRINCIPAL_NAME.
• L’autenticazione dei client Outlook fallisce sistematicamente

Questo comportamento è dovuto al fatto che già l’account del computer inserito in dominio ricopre la funzione di Principal per lo scambio di messaggi Kerberos e accoglie in maniera jolly tutte le richieste di servizio Kerberos. Creare un secondo account utente per questo scopo causa l’errore KDC 11.

Se avete inserito il server Scalix in un dominio AD tramite Samba tutto quello che dovete fare è editare, in active directory, l’account del computer, accedere al tab Delega ed abilitare l’opzione “Considera attendibile per tutti i servizi (Solo Kerberos)”.

Non c’è null’altro da fare.

Prima di avviarmi in questo nuovo articolo dedicato a Scalix, desidero fare una premessa: non intendo far passare il concetto che Scalix sia in assoluto la migliore alternativa ad Exchange. Ci sono altre soluzioni per il groupware messaging, come Zimbra e Zarafa, per esempio che non sfigurano per nulla. Il motivo di questo mio accanimento con Scalix è molto semplice: abbiamo deciso di utilizzarlo e per il momento la decisione è presa. Non si tratta di ingiustificata cocciutaggine quanto, piuttosto, di una attitudine fondamentale che, a mio avviso, deve essere assunta da chi si lancia nel mondo open-source: ad un certo punto bisogna smettere con i test e concentrarsi sul come mettere in produzione una soluzione scelta. Il problema, infatti, dell’amplissima scelta che ci si trova di fronte, porta ad un allungamento spesso smodato dei trial di valutazione e, più si indugia nelle prove di soluzioni diverse più si apprezzano funzionalità diverse, a volte migliori, controbilanciate da carenze a volte essenziali. In questo modo si perde tempo prezioso quando il proprio target è quello di avviare una soluzione affidabile. Il concetto chiave è molto semplice: che si parli di mail server, di crm, di quelchevipare, difficilmente potrete trovare nel mondo open-source qualcosa che si attagli perfettamente alle vostre esigenze, qualcosa che sostituisca e rimpiazzi in modo assolutamente identico la vostra vecchia soluzione closed ed abbia anche – inutile negare che sia uno dei requisiti che molti cercano – la caratteristica della gratuità. Come ho cercato di spiegare in questo mio precedente articolo, ci sarà sempre del lavoro da fare per fare in modo che il nuovo software vesta come un abito su misura e vi aiuti nella gestione dei problemi quotidiani.

Detto questo … un altro aspetto che ho apprezzato di Scalix è la possibilità, con minimo sforzo, di integrare all’interno della medesima struttura, client di posta di natura diversa. Nel nostro caso specifico i due software principali sono Outlook (2007) e Thunderbird.

Ci si potrebbe chiedere perchè ci debba essere necessità di far coesistere due applicazioni che sostanzialmente dovrebbero fare lo stesso lavoro: spesso le aziende (e i fanatici) tendono ad assumere che ci debba essere una sola soluzione standard adottata universalmente, o una o l’altra. Ritengo questo ragionamento piuttosto miope e comunque in contrasto con un principio base : usa lo strumento migliore per ogni condizione di lavoro e per ogni ambito. Del resto, avrebbe senso che tutte le auto aziendali fossero dello stesso modello ed immatricolate tutte come autocarro ? Ovviamente no. Analogamente avrebbe senso dotare di Outlook tutti i pc aziendali quando su molti di essi la gestione della messaggistica da parte degli utenti NON prevede, per esempio, la necessità di condividere le informazioni libero/occupato degli altri utenti ? Ancora, ovviamente, no. Ha senso aumentare lo stack di investimento nel dotare tutte le postazioni di Windows quando molti utenti lavorano solo con applicazioni strutturate di data-entry ? No.

Nel nostro ambito la scelta di adottare Outlook per un certo tipo di utenza e Thunderbird per un altro è stata facile: le caratteristiche delle due applicazioni, costo a parte, sono molto differenti. Certamente entrambe permettono di inviare e ricevere posta elettronica, ma mentre Outlook è molto utente-centrico (gestisce la mia posta elettronica, il mio calendario, mi permette di integrare e sincronizzare le mie device ecc. mentre per “impersonare” utenti diversi devo affidarmi a sistemi di deleghe che non si attivano con un click-e-via), il secondo è estramente più flessibile nella gestione di identità diverse (senza dover riavviare il client tutte le volte), dispone di tonnellate di plug-in liberamente disponibili che possono aiutare nell’automazione di processi ripetitivi (per esempio QuickText), consente la modalità on/off-line senza necessità di componenti aggiuntivi, permette di disporre di identità connesse a Scalix e altre che scaricano la posta in POP da altre sorgenti e consente comunque di disporre di un sistema calendario condivisibile con gli altri utenti outlook (Lightning). Il tutto, ovviamente, a costo di licenza zero.

Tra l’altro, in ogni momento, gli utenti Thunderbird possono comunque accedere al simil-outlook offerto dall’interfaccia web di Scalix (Scalix Web Access) il che rende trasparente la base dati comune.

Collegare Outlook a Scalix è immediato: basta installare il connettore Scalix Connect per Outlook e configurare un nuovo profilo di posta connesso a Scalix Server. Una nota importante riguarda l’adozione di Scalix Smart Cache: se state configurando la posta per un desktop evitate di attivare Smart Cache in quanto difficilmente potrà accadere che vi sia la necessità di lavorare in modalità Off-line. Al contrario, se state configurando Outlook per la connessione a Scalix su un laptop o comunque su un portatile, vi tornerà utile attivare Smart Cache per le attività di consultazione della posta fuori rete.

Per quanto riguarda Thunderbird la connessione al server Scalix avviene tramite connessione IMAP.  Il difetto (si fa per dire) di Thunderbird è che al momento della prima connessione cercherà di creare sul server IMAP a cui è connesso, le cartelle fondamentali per il proprio funzionamento. Generalmente questo non è un problema ma se si desidera che la struttura delle cartelle con Thunderbird sia la medesima che viene visualizzata con SWA ed, eventualmente, anche utilizzando Outlook, è bene comprendere quale sia la struttura delle cartelle lato Scalix Server e come renderle obbligatorie per Thunderbird.

Se infatti si tenta di aprire il medesimo account una volta con Thunderbird e una volta con Outlook, ognuno dei due client creerà delle proprie cartelle che avranno significato particolare solo per quello specifico client. Ad esempio : Outlook (tramite il connettore Scalix) onora i nomi standard in inglese delle cartelle MAPI di base che sono Inbox (Posta in Arrivo), Outbox (Posta in Uscita), Waste Basket (Cestino), Calendar (Calendario), Contacts (Contatti), Tasks (Attività), Journal (Diario), Drafts (Bozze), Notes (Note) mentre, per la versione localizzata in italiano, la cartella della posta indesiderata viene chiamata appunto ‘Posta Indesiderata’ al posto dell’omologo in inglese Junk. Volendo condividere le medesime impostazioni tra Outlook e Thunderbird dovremo avere l’accortezza di configurare Thunderbird in modo che la cartella della Posta Indesiderata sia proprio quella scritta in italiano. Per eseguire questa impostazione basta accedere al menu Strumenti -> Impostazioni Account di Thunderbird e nell’apposita sezione modificare il nome della cartella di posta indesiderata.

Il mio consiglio è quello di accedere per la prima volta ad un account con Outlook, prendere nota dei nomi delle cartelle, e quindi modificare le impostazioni di Thunderbird di conseguenza.

A questo punto potete installare il plug-in Lightning per Thunderbird ed accedere al calendario associato all’account sul server Scalix. La configurazione è immediata. Create un nuovo calendario remoto (Sulla rete) di tipo CalDAV ed inserite come percorso la seguente riga :

http://<nome-del-vostro-host-scalix>/api/dav/Calendars/Users/<indirizzo-email-utente>/Calendar

Dopo la configurazione iniziale vi viene richiesto di inserire la password dell’account a cui appartiene il calendario … et voilà, anche su Thunderbird il calendario di Scalix con promemoria e allarmi come lo vedete (e impostate) su Outlook.