Thunderbird a propojení s Microsoft Exchange (diskuse)

[jiri]

Nikdy jsem exchange server nepoužíval a nikterak ho neznám, ale k čemu je to vlastně dobrý? Proč nepoužívat kombinaci IMAP/SMTP/Submission a kalendář neřešit třeba jen ve webmailu, když dnes z mé zkušenosti většinou lidé moc často standardního mail klienta nepoužívají? A sdílené složky snad IMAP také implementuje (konkrétně Dovecot například, a velmi dobře).

[Max]

Ve firmě je klient docela velké slovo. Doma použiješ webmail apod., ale ve firmě moc ne, jednoduše proto, že webmail nedostačuje. Problém webmailu je přecijen pomalosti oproti klasickému klientu (teď nemyslím ajax user friendliy rozhraní), nemožnost cachovat (stahovat maily s přílohami do pc pro rychlejší práci), ač toto by už třeba gmail měl umět, ale s gmailem jsme zase někde jinde.
Dále tu máme indexování emailů a jejich rozšířené vyhledávání, v případě Exchange + Outlooku se bavíme o Windows Desktop Search.
další problém webmailu jsou notifikace o příchozím emailu. Standardně nejsi nijak upozorněn o příchozím emailu. Dá se to řešit externí aplikací do systray, která kontroluje schránku přes imap/pop3.
Spíš než sdílení složek je rozšířenější sdílení kalendářů - direktorium ví, kde kdo je, na kdy má jakou schůzku, kdy a kde koho může zastihnout, sekretářka může naplánovat schůzky, aniž by někoho obtěžovala atd. Kalendář a plánování, to je neocenitelná věc pro vedení.
Zdar Max

[davadu]

Ono je to dobré např. na to, že existují naprogramovaná propojení na informační systémy. Např. v IS se naplánují schůzky, porady a to se převede jednoduše do Exchange do sdíleného kalendáře nebo přímo do osobních kalendářů účastníků. Díky ActiveSync se jim to zobrazí na mobilních zařízeních nebo v Outlook/Evolution nebo ve OWA (Outlook Web Access).

Pokud používáte vyšší verzi Exchange, tak je možné přímé propojení s pobočkovou ústřednou, kde Exchange může dělat "plechovou hubu". Umí předat záznam volání do mailu, poslat SMS o přijatém hovoru a podobné ptákoviny.

Jiná píseň je, že v snad v 90% se Exchange používá stylem SMTP/MAPI/IMAP/Webmail. Což je tak asi 10% z jeho funkčnosti.

[Max]

Jinak proč se používá, je to klikací, člověk to rozjede relativně rychle a v pohodičce, všude ve firmách jsou Office, takže emailový klient je dostupný a nemusí se nijak řešit, maily uložené v databázi (oproti Maildiru je třeba backup takových emailů opravdu rychlá věc), což umožňuje různé optimalizace IO operací apod. věcí. Těch výhod je samozřejmě více, ale toto je takový základ. Apropo, neřešil někdo ukládání emailů třeba do Postgresql db, a pokud ano, co jste použili?
Zdar Max

[Ivan]

Zrovna zalovani a restore mailu na exchange je porod. Je hezky, ze to uklada maily do databaze, ale proc to musi byt zrovna Access. Proc nepouziji SQL server? Treba Veritas Netbackup pro exchange spousti nejakou Exchange binarku, ktera exportuje jednotlive ucty do binarniho souboru do TEMPu a tyhle soubory jsou pak kopirovany na pasky. Ve vysledku je to cele neuveritelne pomale. Exch. samozrejme umi zazalohovat i celou DB najednou, tak je ale jedina moznost obnova cele DB, coz vetsinou ale nikdo nepozaduje.

Do databaze daval maily "Oracle Mail" - melo to binarky pro MDA, POP3, IMAP - binarky byly spousteny z inetd. Pred deseti lety to vice-mene v pohode zvladalo ulozt desitky GB mailu do DB. Tehle produkt uz ale neexistuje.

Pokud na zalohovani maildiru pouzijes TSM, tak neni problem. TSM si pres neco jako inotify nechava od kernelu posilat infomace o tom, ktere soubory byly zmeneny. Tyhle informace pak udzuje v zurnalu. Samotna inkrementalni zaloha je pak velice rychla.

[Max]

My používáme Ca ArcBackup server a je to zajímavé. Někdy trvá záloha 7 hodin, jindy 18 hodin. Ovšem umožňuje obnovit i mailbox.
Pokud jde o ten Veritas Netbackup, tk jestli pak nepracuje s mailboxexport cmdletem. To by vysvětlovalo všechno :).
TSM? To jsem nevěděl, že až takto. Hmm, tím pádem jeden důvod, proč použít db padá a druhý už není tak podstatný.
Zdar Max

[platYpus]

Ta stara verze (viz. nize muj predchozi prispevek) pracuje na bazi MAPI. V podstate emuluje MAPI-klienta (obnobne ako je EXMERGE) a vytahne jednotlive maily do souboru a ty potom TARem na pasky ci na disk.

Dneska se to uz takhle nedela, nicmene z duvodu zpetne kompatibility je tato moznost stale k dispozici.

[platYpus]

Pouzivas starou verzi NetBackupu (resp. stare postupy v nove verzi a pak se divis ).

Toto se pouzivalo driv, kvuli per-mailbox zaloham. Presneji receno, tato metoda se kombinovala s klasickou databazovou zalohou ktera je ryhchla dostatecne (u nas v podniku dokaze bez problemu saturovat LTO3 mechaniku na plny vykon).

Tato doplnkova metoda spocivala v tom, ze se pomoci MAPI vytahly jednotnotlive objekty a pak bylo mozne (narozdil od klasicke databazove zalohy) obnovovat jednotlive mailboxy ci maily. A to velmi rychle. Dalo se to delat jak pres disk, tak i primo proti paskam.

Dneska uz se to takhle nedela, protoze je tu s nama NetBackup GRT. To pracuje na bazi klasicke databazove zalohy, s tim rozdilem, ze k ni pridava jeste index. Obnova je pak mozna rovnez na urovni jednotlivych mailboxu ci mailu, ale neplati se za to onou vyse zminovanou pomalosti zalohy.

NetBackup je jeden z nejlepsich nastroju na zalohovani Exchange. Staci ho umet pouzivat.

[petr_p]

Přímo z webu Dovecotu je odkazovaný dbmail, ale zároveň vývojáři Dovecotu říkají, že SQL for IMAP back-end sucks.

[Max]

Ajaj, o dbmailu vlastně vím, jen jsem o něm slyšel hodně dávno a nevzpomněl jsem si.
Zajímavé počtení a zajímavý názor (SQL just sucks).
Zdar Max

[pavlix]

Ukládání dokumentů do SQL je technicky možné, ale je otázka, jestli to má vůbec nějakou výhodu.

[Max]

Kromě několika nevýhod si myslím, že výhoda je právě třeba v optimalizacích zápisu/čtení, které by měly být u db zákonitě mnohem lepší, než u klasického Maildiru.
Dalším bonusem by mohla být jednoduchá konzistentní záloha, což u Maildiru asi nehrozí (pokud člověk nepoužívá nějaký snapshotovací FS).
Zdar Max

[Honza Jaroš]

Aha, pořád jsem tuhle výtku nechápal a až teď mi došlo, že všude používám LVM a zálohuji přes rdiff-backup. Ty snapshoty se zaryjou pod kůži.

Přiznám se, taky dávám přednost maildiru před databází. Je fakt, že nikde neprovozuju mailserver pro tisíce uživatelů a na stávající počty maildir bohatě stačí, navíc Dovecot si udržuje nějaké svoje vlastní indexy pro zrychlení přístupu...

[Heron]

Tak jistě že ano. Na rozdíl od většiny systémů souborů jsou databázové systémy přímo optimalizovány na velký počet záznamů a umí s nimi dobře zacházet. Ještě mi to nikdo nevyvrátil, naposledy jsem testoval (všemi doporučovaný fs pro velký počet souborů) Reiser a už při pouhých 100mil. souborů to šlo do kolen. Zatímco v DB jich bylo připraveno ještě dvakrát tolik. S tím FS nešlo pracovat, jediné co se dalo dělat bylo lvremove, zatímco ta DB byla stále svižná a rychlá.

Pokud k tomu přičteme i to, že email je potřeba "adresovat" pomocí daleko více klíčů, než je název souboru (ten vlastně potřeba vůbec není a je zaveden uměle), tak je použití DB ještě více jasné a souborový systém tady už nemá co nabídnout.

Dále, a to zminuje i v tom emailu, tam píše, že mají napsané vlastní indexy nad maildirem. Já jim to neberu, dovecot je v tomto dobrý, ale přijde mi to jako tříštění sil. Síla Unixu je ve využívání již hotového. Nevím proč by každý projekt zabývající se emaily musel stále dokola řešit způsob uložení, způsob indexování, zpracování apod, když už je to dávno napsané a optimalizované experty na tato témata.

[Heron]

Dále DB má pochopitelně i vyšší rychlost. Nevím, zda vůbec existuje FS, kterému lze předat seznam souborů k přečtení a ten by potom optimalizoval jejich čtění pro app -- čtení v pořadí, jakém jsou na disku, dopředné čtení dalšího souboru apod. Myslím, že neexistuje.

Zatímco DB, pokud jsou její data uložena na systému souborů, může využít hned několika fint. Jednak je to readahead samotných pevných disků a potom i přednačítání ze strany OS. Takže se snadno stane, že bloky jsou již dávno v IO cache paměti.

Dále, opět na rozdíl od FS, DB může uložit záznamy v pořadí nějakého klíče. Takže čtení různých záznamů proběhne sekvenčně. Na disku by se muselo seekovat, opět neznám fs (nebo spíše volání kernel api), které by vynutilo zapsání souborů přesně na daný blok.

Dále, na jednu datovou stránku DB se vleze těch záznamů (emailů) hned několik. Může to být komprimované. Opět, přečtení jedné datové stránky znamená přečtení hned několika záznamů.

Je samozřejmně otázka, zda a jak by se toto všechno využilo v praxi, každopádně už z principu to nemůže být o moc pomalejší, než na systému souborů.

[Ivan]

JJ, napriklad Linux kernel neumi drzet v buffer cache kus inody s aresarem. Bud ma v pameti vsechno nebo nic. Pokud mate adresare, ktere obsahuji stovky tisic souboru, tak potrebujete spoustu pameti. Zatimco DB muze drzet v buffer cache bloky podle priority indexy, data, bloby(prilohy).

[Martin]

Pokud máte na Exchange více Referrals, je lepší použít Global Catalog Search na portu 3268. Je rychlejší, a spolehlivější, protože klient se nedoptává jiných LDAP serverů (které třeba z VPN nemá routované).

[JoHnY2]

Kdyz je tu zminka o mailu obecne. Mate nekdo zkusenost s nejakou predpripravenou jednoucelovou distribuci, ktera by resila IMAP/SMTP/WebMail?

[Max]

Ahoj, zkušenosti s tím nemám, ale slyšel jsem např. o "iRedMail", což je postfix+dovecot+mysql+ldap+roundcube+spam+antivir+atd.
Možnost placené verze se supportem atd.
Zdar Max

[lm]

vdaka za upozornenie na davmail :)

[Kaacz]

lol, tohle mne rozesmalo :

To nejjednodušší je přenos emailů. Nejlepším řešením je mít na Exchange zapnutou službu IMAP a povolenou pro příslušné uživatele.

Reseni mozna nejlepsi, ale ve velkych firmach je to utopie. Zkouseli jsme to nekolik roku, aby to nasi IT odbornici povolili. Proste jediny spravny klient je Otlak na jedinych spravnych Widlows a basta.

Mno ale dozvedel jsem se o DavMail gw, tak treba se povede te konzervy evolution zbavit.

[Max]

Mno, já znám zase IT odborníky, co mají Exchange a používají pop3, až teď pomalu začínají přecházet na mapi.
Zdar Max

[ludvik]

a já mám pro změnu outlook na imapu a je to děsné.

[brk]

Tak to je kapitola sama pro sebe. Osobně mám pocit, že si Ms uvědomuje, že spousta lidí nepotřebuje kalendář a další věci kromě pošty, na jejichž synchronizaci by IMAP stačil a tak záměrně maximálně zprasil jeho implementaci, aby bylo vidět, že pokud má Outlook pracovat opravdu dobře, tak potřebuje Exchange.

[Heron]

+1

Outlook je skvělý klient, ale pro IMAP nepoužitelný. Přitom MS to umí, Outlook Expres (dneska asi jen Mail z balíku Live) nemá s IMAPem problém. Ale zase se nedá používat.

[brk]

Tak to je "kvalita". Windows v doméně, spustím Outlook, kliknu 3x na next a mám funkční poštu a vše okolo bez toho, aniž bych musel něco napsat.

Evolution relativně v pohodě. Starší verze mi fungovala celkem OK, i když hodit něco do kalendáře a přizvat i ostatní mi už nějak nešlo. Nějaká novější verze už na GTK+ 3 mi dělá psi kusy.

Tohle je ovšem masakr. Věřím, že to nějak fungovat bude, ale kdo má čas si v práci "hodinu" ladit Thunderbird?

[JoHnY2]

A presne to co popisujes je duvod proc jeste Linux neznicil instalacni zakladnu Windows serveru ve small bussinessu. Ac dokaze bejt Exchange pekna mrcha, obzvlast pri integraci s domenou do Win SB Serveru, tak je to hodne schopnej kus SW.

[Bedňa]

Ty každý deň nanovo inštaluješ systém? A čo to je za prácu, keď si tam každý robí čo chce, nieje tam voľné miesto

[LuděkS]

Souhlasím. Nedávno jsem se snažil Thunderbird použít jako náhradu plnohodnotného Outlooku a přinutit ho ke smysluplné spolupráci s mailovým serverem ve všech funkcích, které Outlook dobře zvládá a použít ho jako aplikaci pro spolupráci, ale moje zkušenosti jsou přinejmenším hodně rozpačité. Zbytečně komplikované nastavení, nejrůznější bugy v Thunderbirdu i v doplňcích (a také v lightingu )
Podotýkám, že to pro mne nebylo nové prostředí, protože jsem používal ještě Netscape / Mozillu / Seamonkey.
Ale stav, v jakém Thunderbird je (včetně jeho doplňků) mne dost nemile překvapil.

Z toho důvodu také nerozumím tomu, proč Ubuntu zařadilo Thunderbird jako defaultní aplikaci místo Evolutionu. Jediné co mne napadá (ale to se jen tak utěšuju), že by to mohlo Thunderbirdu třeba pomoct. Jestli je to tedy vůbec možné...

[SyncKolab]

ahoj, nezkousel jste nekdo s Exchange rozsireni SyncKolab? http://addons.mozilla.org/addon/sync-kolab/ Nepovedlo se mi ho zcela rozchodit, tvari se ze stahuje, ale nic nedela...funguje to nekomu? diky za odpoved

[jakub]

Dobry den, umi nekdo dostat do Thunderbirdu vsechny slozky, ktere jsem si v Outlooku vytvoril?
Nejenom "Inbox"?
Diky

[Max]

Pokud se složky nacházejí na serveru, v mailboxu uživatele, tak není problém a natáhnou se do thunderbirdu úplně normálně (jako složky imap). Pokud si složky vytvoříš u sebe v outlooku a jsou uloženy na disku, tak export / import, popř. jiný druh migrace.
Zdar Max

[Max]

Tak se objevil další doplněk, který je alternativou, nebo náhradníkem doplňku "Provider for Microsoft Exchange"
Je jím : Exchange 2007/2010 Kalender en Taken Provider, který je konfiguračně skoro stejný jako předešlý doplněk, ale umí toho daleko víc a možná bude i lépe fungovat. Zatím jsem nezkoušel, ale vypadá to, že má větší budoucnost. Zatím ho testuje jeden známý.
Zdar Max

[Max]

Nejlepší aktuální verze viz : exchangecalendar-3.3.0.xpi na githubu.
Zdar Max

[Peter]

Zdravím, chci se zeptat, v práci jsme začali používat exchange. Každý má Outlook, já osobně používám Thunderbird portable verzi protože mi vyhovuje více. Mám problém v tom, abych viděl kalendáře kolegů a hlavně abych viděl jejich úkoly a mohl je spravovat. Máme rozběhlou i OWU, kde úkoly a kalendář kolegům spravuji, respektive přidávám jim práci, je možné toto dělat i v thunderbirdu? Lightening či jak se doplněk jmenuje už mám nainstalovaný, protože díky jemu běží můj kalendář s mými úkoly. Na exchangi máme nastavená veškerá práva, jde mi spíše o to, jak dostat kolegů kalendáře a úkoly ke mě do TB. Díky s pozdravem Peter

[Max]

Nezkoušel jsem, ale sdílený kalendář by měl jít přidat jako tvůj vlastní kalendář (pokud používáš mnou popsaný plugin výše "exchangecalendar-3.3.0.xpi", který umí i fci mimo kancelář), jen s tím rozdílem, že url bude na jiný mailbox (prostě toho, kdo to sdílí) a login a pass budou tvé údaje. V kroku, kde se tě bude průvodce ptát, k jakému účtu kalendář přiřadit, bych zvolil "none".
Vyzkošej a dej vědět.
Zdar Max

[Peter]

Díky za radu, dáš mi pls link, kde bych to našel?

Díky Peter

[Max]

Dám ti jen radu, aby jsi si pořídil lepší brýle, viz můj komentář, co je těsně před tvým prvním komentářem
Zdar Max

[Peter]

:D Díky, přeci jen 6 dioptrií v tuhle dobu s čočkama už se dá pochopit, když se mží :D

[Peter]

Super, kalendáře jsem si natáhl. Půjde to i s úkoly vyřešit, abych je viděl?

Díky Peter

[Max]

Netuším, úkoly jsem nikdy nepotřeboval.
Zdar Max

[Peter]

Ahoj, tak to nakonec funguje i s úkoly kolegů, vidím jak své, tak jejich a mohu jim je i přidávat. Díky Peter