Exchange lecserélése postfix-re

 ( gyuri23 | 2019. június 17., hétfő - 7:50 )

Sziasztok!

Adott egy cég 150 user és még 50 shared mailbox. Jelenleg AD + Exchange 2007 van amiből a teljes levelezést át kell rakni postfix alá. Naptár és task használat gyakorlatilag nincs, az új rendszerben nem is igény. A kliensnek jelenleg Outlook 2007-2010-et használnak, ennek a cseréje nem szükséges nincs rá megkötés, csak az, hogy ha csere lesz, nem lehet licenc költség, pl. Thunderbird.

Jelenleg két irányban gondolkozom. Az első: elkészíteni mindent az új szerveren, beállítani minden kliensen az új szerveren levő mailbox-ot is, és utána „egy mozdulattal” átállni. A levelek migrálása valószínűleg nem fog beleférni (max 1 nap lehet), ezért megmarad a „régi” mailbox is. Itt attól tartok, hogy a felhasználók bele fognak kavarodni, hogy hol vannak a régi leveleik, ha rossz helyről küldenek miért nem megy el a levél, nem jön válasz stb.

A másik verzió az „egyesével” átállás. Itt az adminisztrálás kicsit macerásabb, felvenni két ideiglenes domain-t, hogy irányítani lehessen a belső levelezést forward szabályokkal. Mivel nem Exchange mindkét szerver, ezért erre nincs jobb ötletem. Viszont így a helyi helpdesk akár migrálni is tudja a leveleket az új mailbox-ba és a felhasználóknak egyértelműbb lesz az átállás. Így nincs határidő amivel szívni lehet, mivel folyamatosan lehet átrakni az user-eket az új szerverre.

Ha valaki már csinált ilyet megoszthatná velem a tapasztalatait, hogyan csinálta és mivel szívott, ha volt gondja egyáltalán. Hogyan migrált, van valami megbízható PST → IMAP (MailDir) konverter? Hogyan oldotta meg az egy domain Postfix + Exchange párost?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én egylépésben migrálnék ennyi mailbox-ot.

A user már a Dovecot-ba jelentkezne be, onnan levelezne, a bejövő levelek oda érkeznének, a háttérben pedig mehet az IMAPsync.

OWA-t esetleg elérhetővé teheted a migráció alatt, vagy, ha cached mode-ban vannak az outlook-ok, akkor lokálisan elérik a mailboxokat, kapcsolat nélkül.

Nekem az az emlékem, hogy az Exchange támogat IMAP-et is. Ha így van, akkor a migráció tudhat IMAP->IMAP lenni, amihez vannak tool-ok.
--
https://naszta.hu

Egy hasonló frissítés tanulságai (nem exchange-ről, hanem courierről dovecotra):

- Mindenképp szívás.
- Egy lépéses nem javasolt, a kliensek konfigurálása miatt (nálunk kicsit más volt a helyzet, felhasználónevek is változtak, szóval minden kliens újra letöltötte a teljes levelezését).
- ha párhuzamosan fut a két szerver, akkor jól meg kell tervezni a levelek útvonalát, könnyű loopokat gyártani.

Végül ami a legkisebb fájdalommal járt nálunk: berakni régi szerver elé egy SMTP/IMAP proxy-t, majd a proxy mögé bekötni a régi és az új szervert is. Aztán egyesével migrálni a fiókokat, a proxy meg eldönti, hogy kit melyik szerverre dobjon tovább.

--
40% of OpenBSD installs lead to shark attacks. It's their only standing security issue.

Köszi. Hogyan oldottátok meg a proxy-n, hogy eldöntse hová kell küldeni a belső->belső leveleket? A guglin a legtöbbször a +2 domain használatát találtam. Pl felvenni alias-nak a regiszerver.lan meg ujszerver.lan címeket és azokkal forward-olni keresztbe a két gépen.

IMAP proxynak perdition-t használtunk, SMTP-t meg nginx-el oldottuk meg. Egy sql alapján döntötték el ki hova tartozik.

--
40% of OpenBSD installs lead to shark attacks. It's their only standing security issue.

perdition mennyire stabil ?

Mi erre ahol kell Dovecot + Exim-et használunk, szintén SQL-ből.
Nincsen velük gond, csak kíváncsi vagyok.

Nginx SMTP-t mi is próbáltuk, de exim jobban bejött.

Semmi gond nem volt eddig vele, mondjuk nem túl bonyolult a feladat se amit megold.

--
40% of OpenBSD installs lead to shark attacks. It's their only standing security issue.

Mi ugyan postfix->postfix migrációt csináltunk, de az "egyenként" megoldást választottuk úgy, hogy folyamatosan karbantartottunk a szervereken egy transport map-et, ami user-enként külön-külön definiálta, hogy melyik szerverre kell épp kézbesíteni az adott címet. Így nem kellett semmi átmeneti plusz domain-t bevezetni. Talán exchange-ben is tudsz definiálni hasonlót.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Hú köszi, nem is tűnt fel eddig, hogy a transport map-ba konkrét email címet is lehet írni, ráadásul a helyi domain-ből is. Ez tényleg egyszerűbb.

Sőt, még csak domain-nek sem kell lennie (lehet "local" meg IP is a cél).
Az ugye megvan, hogy a Postfix csak félig tudja kiváltani az Exchange-et?

Igen, de ott konkrétan a negyedét sem használják. Kívülről nem lehet használni, nincs owa elérés, se activesync, naptárt senki sem használ, csak munkaidőben lehet dolgozni :) úgyhogy bőven elég lesz a postfix/dovecot, még webmail sem kell.

(csakmert a Dovecot-ot eddig nem emlitetted :) )

Nálam valahogy egyben van :) Eddig üzemeltetek pár Zentyal-t meg iRedmail-t, de most úgy gondoltam jöhet a nyers postfix/dovecot. A Cyrus túl soknak tűnik, bár érdekelne, hogy mennyire megy a Caldav-benne.

Nekem 2.5.10-es verzióval működik.
A Carddav is.

Milyen klienssel használjátok és mennyire megbízható?

Thunderbird (Lightning,Cardbook).
Nem olyan régen próbálkozom vele, de ígéretesnek tűnik.

O365-ön nem gondolkoztatok el, ha már eddig is MSFT volt?
--

Az nincs játékban, mert a licenc költsége nem nulla :) meg a cég nem hajlandó bérelni semmit, csak olyan szoftvert használ amit meg lehet venni és saját tulajdona lesz.

Hát ezt nem túlzottan értem, az exchange 2007-nek 0 licenszköltsége volt? Az AD usereknek vagy a desktop windows-oknak vagy office/outlook-nak nem volt licenszköltsége? Annyi változna, hogy most nem 1 összegben fizetsz ki 10M ft-ot, hanem mondjuk 3-4 év alatt. Aztán tovább is addig kell fizetni, amíg használod.
--

Gondolom eddig volt, mostantól pedig már nem lesz.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Akkor jó ötletnek tűnt :) Igazából meg árérzékeny a cég, az Exchange extra tudásából (a levezésen felül) semmit sem használnak. Így elég nehéz indokolni miért fizessenek bármilyen licencre amikor van open megoldás. Az összes fizetős licenc a sov24-ről van. Az MsOffice csere is tervben van LibreOffice-re.

Uh. Azert arra figyelj, hogy teged biztosan kifizessenek!

.

Ezt szerintem nem jól látod. Én 15-20 cégnek dolgozom és nem mindenki "árérzékeny". Van olyan cégem ahol csak a sebesség számít, ami gyorsabban megvan és ellátja az igényt az kell és tök mindegy mennyibe kerül. Jelen esetben annyit tesz az árérzékeny, hogy nem eszik meg a marketing bullshitet a felhő faszaságáról, meg ha az Exchange tudásából nem kell nekik semmi, akkor minek fizessenek.
Volt olyan esetem is ahol csak azért lett Exchange mert a főnök naptárat akart használni. Rajta kívül mindenki senki nem használt semmit a levelelzésen kívül. Próbáltuk lebeszélni, de neki az kellet és kész, azt mondta kifizeti.
Szóval nem mindenki árérzékeny...

Szigorúan szerintem, de az Exchange nagyon jól használható vállalati környezetben, jól tette a főnök, hogy bevezette és az emberek elkezdik kihasználni.
--
https://naszta.hu

Ha fontos az, hogy az adataidat saját szerveren tárold, akkor nagyon sok negatívuma van az exchange-nek, miközben 100%-ig kiváltható linux alapú szerverrel (naptár és outlook integrációt is beleértve).
Egy linuxos rendszer sokkal stabilabb, dinamikusabban konfigurálható, szerverkihalás esetén gyerekjáték újra felhúzni, stb. Az exhange-nek óriási az erőforrásigénye, bármilyen probléma esetén jelentős idő helyrehozni, szerver kihalás esetén akár napokba is telhet az újrahúzása, elég nehéz backupolni, stb.

Nálunk is volt több exchange próbálkozás, de szerencsére még mindig postfix megy többek között az általad is említett tulajdonságok miatt.

"közben 100%-ig kiváltható linux alapú szerverrel (naptár és outlook integrációt is beleértve)."

Na ezt viszont nem sikerült még implementálnunk. Tudnál adni néhány támpontot?

Nekem jó tapasztalatom van a SOGo 3.x és 4.x verziókkal. Elég jó a CardDav, CalDav megoldása, Outlook kompatibilis teljesen, remekül kezeli az egyéni és közös címjegyzéket/naptárat a weben és klienssel csatlakozva is.
Persze nem olyan, mint az Exchange/Outlook, ahol OOB megy minden (na jó, ott sem OOB, de úgy tűnik elsőre :-). Itt azért ezt-azt konfigolni kell. De valóban megoldható a legtöbb funkció.

Kolab, Outlook usereknek (meg Androidosoknak is) van benne EAS.

Dolgoztál egyébként kisvállalatinál nagyobb Exchange organizációval?

Igen, a cégünk fő email szerver exchange 2008 óta, akkor én telepítettem. Most egy windows srvs kolléga kezeli, de vannak vele bajok... Ez mellett sok linux alapú e-mail szervert kezelek és jól látom a különbségeket.

Exchange Online-ban 200 user listaáron 200.000 Ft havonta (nem túl nagy az ügyfélszám, de elképzelhető, hogy ebből kapsz kedvezményt), ebben benne van a szerver és ügyféloldali licensz és a mögötte lévő felhős
- egyébként NATO kompatibilis - infrastruktúra.

A migrációt követően gyakorlatilag egy nagyobb IT-s tudással rendelkező, business oldalról jövő belső kolléga is képes managelni, folyamatosan nem szükséges IT-s jelenlét rá.

Mennyi a teljes költsége mindennek, on-prem környezetben, linuxos infrával?

Idézet:
The Microsoft Online Subscription Program (MOSP) is a subscription-based Microsoft Volume Licensing program

És a business oldalról jövő nagyobb IT-s tudással rendelkező kolléga fogja managelni a Microsoft audit megkereséseit is ? (az lehet drága lesz :))

Idézet:
It's even worse than email. Now they are sending direct mail to all of my Office 365 tenants....

Time to start pitching Gsuite a hell of a lot more.

https://imgur.com/qdtXGb0

Jó a reklám :)

A kérdésedre fillérbaszóknál az áram amit a "szerver" megeszik és a netkapcsolat (ami ugye adott) . Amúgy kétlem, hogy egy control panelen sokkal nagyobb cucc összekattintgatni a dolgokat :))

Konkrétan milyen Microsoft audit megkeresésre gondolsz?

Gondolhatok a fenti X évente ismétlődő auditra hajazó v-endor@microsoft.com feladós sales pitchre. (biztos van olyan akinek bejön az ilyen fajta sales :))

Vagy az igazira is. Bár lehet ez speciális VL szerződés aminek nincs "Verifying compliance" része. :)

Idézet:
We've just had a chat with a Microsoft SAM Engagement Manager, our client is being reviewed and they have no VLA with Microsoft. Microsoft say that Office 365 is seen as a VLA and because of the global increased use of Office 365 they are now performing SAM reviews for Office 365 users.

Forrás (SAM Review for Office 365?) (Gondolom az Exchange Online is annak látszik :))

Azaz befizetsz egy ilyenre és a biznisz guy szaladgálhat is az összes Microsoft-ot tartalmazó számláért. :) (persze szigorúan opcionálisan, annak tudatában, hogy a következő levél lehet már a nem opcionális verzió lesz (már csak azért is gondolom, hogy van ilyen kitétel mert amúgy a SAM Review-oknak se lenne jogalapja) ;))

Ugye itt arról van szó, hogy a Microsoft levélben, vagy - amennyiben van - a kapcsolattartón keresztül elképzelhető, hogy felajánlja, hogy segítséget nyújt a software inventory elkészítéséhez.
Természetesen a közreműködés opcionális és retorziómentesen visszautasítható.

Mivel itt összesen 200 db online licencről beszélünk, nagy valószínűséggel nem is fog foglalkozni vele a Microsoft Hungary.

Négy évente felajánlja? A levelükben miért nincs benne, hogy opcionális? :D

Sőt a fogalmazás is erősen arra hajaz:

Idézet:
Kérjük, igazolja vissza az e-mail megérkezését, és erősítse meg, hogy a Telepítési összesítő kitöltését éééé.hh.nn. határidőig elvégzi.

Még szerencse , hogy határidőt is adnak a segítséghez. És a felajánlásokban nem használunk felszólító mondatokat, ha pedig már "segítünk" a kommunikációban passzív-agresszív hangnemet meg pláne nem. :)

Idézet:
Mivel itt összesen 200 db online licencről beszélünk...

Arról beszélünk mit jelent a vele járó VLA egy olyan SMB-nél ahol nincs VLA. Szerintem instaflagot SAM review-ra (amire egyébként one man show IT-nél sincs erőforrás, te meg elvileg az Exchange Online-al megspóroltad az IT-t). :)
Amúgy persze, hogy az MS nem fog. Majd egy "független" vendor. Főleg ha előtte nem volt VLA , gyorsan fel kell mérni mi is van a on-premise a cégnél.

A retorziómentességre se vennék mérget, szerintem simán behúzzák a cég neve mellé a strigulát így előnnyel indulhat a sorsoláson a nem szívességi alapon történő auditért. :)

Off: Amúgy én lehet elfogult vagyok, mert az első "segítségüknél" a határidő előtt egy nappal a pszichiátrián kötöttem ki (tisztán emlékszem, hogy a doki XP-s gépen nem volt COA matrica...)
Pedig a licenceléssel akkora gáz nem volt (pár lekopott XP matrica, és egy darab elveszett office 2007 basic kulcskártya (ami megkerült))

Én simán visszaküldtem, hogy most nincs időnk ezzel foglalkozni, később térjünk vissza rá.
Évente 100 millió Ft felett fizettünk az MS HU-nak.

+1, mi lesz, ha nem kuldod vissza? Nem fogjak megujitani a VL-t, amiert milliokat fizetsz? Ugyan mar. :)

Nem kell kummantani a licencekkel, es akkor nem kell aggodni ilyen self-auditok miatt. Majd ha nagyon auditalni akar egy vendor (es ne gondolja senki, hogy csak a MS ilyen segitokesz), akkor lesz szives a humaneroforrast is biztositani hozza.

Nem a kummantásról van szó hanem a melóról ami az igazolással jár, végigkúszni minden gépet, összegyűjteni a számlákat (12 éves vasaknál ez se mindig triviális feladat), coa fotót. Licenccelési kérdésekről nem beszélve, mert a túloldalt se igazán licensing expert ül sokszor. (Gyári Vista downgrade az most Vista vagy XP és társai és voltak olyanok amik minnél több utánolvasás után egyre kevésbé voltak értelmezhetők pl az egyetlen azóta hálistennek nyugdíjba vonult így már nem is létező "per server" licenszelésű Windows Server miatt két hétig azzal álmodtam, hogy a rajta lévő SQL Expresst csesztető belső webapp miatt kell-e CAL vagy nem kell-e CAL (ugye olyan régi szervernél még nem volt "web workload")) Így az , hogy megveszel valamit, baromira nem jelenti automatikusan a compliancet (náluk meg bőven van mit átrágni ahoz, hogy el tudd dönteni vagy még jobban belekavarodj. A nagy kérdés kinek van erre ideje? ;))
Persze közben csinálni a dolgod amit egyébként egy biznises kolléga is össze tud kattintgatni exchange onlinenal.

Eleve a MSFT licenszelése olyan, h. ha bemész a graphisoft parkba, és lerángatsz tőlük 3 sales-est, 3 totál különböző szám fog kijönni a végén. Ja, és még bilincses plakáttal téged fognak fenyegetni utólag ha nem a legmagasabbat fizetted ki végül. Innentől ez a maffiaszervezet tehet 1 szívességet. Onnantól pedig h. adtál nekik 1 petákot is aláírt papír szerint, bekerülsz a zsarolási rendszerükbe, és a világ végééig (de legalábbis a leszármazottaid kipusztulásáig) a nyakadra fognak járni a piócáik. Azt a pénzt, amin nutelláék űlnek, nem tiszta lelkiismerettel tudták összeharácsolni.
--

Nem koltoi kerdes volt: mi van, ha megirod nekik, hogy majd ha kuldenek ok egy auditort, akkor majd szivesen segitesz neki, de neked erre nincs idod?

Engem is szorakoztattak anno, hogy vigyem ki az ugyfelekhez a MAP Toolt, mar en sem vettem komolyan, pedig ott dolgoztam.

Ilyen válaszokhoz én kicsi vagyok, meghagyom a főnökeimnek.
(akik amikor a VL-es szerződést kötötték se kérdeztek meg (szerintem gőzük sem volt mit írnak alá, ha akkor született amire én gondolok egy felújításos pályázat volt, pénz volt és jelenleg a pártízmilliós MS rendszer ott rohad el vagy leginkább rohadt el mert vagy 10 éve volt ahova beüzemelték (azok nem mi vagyunk :)) mert nincs/sohasem volt rá üzemeltető (az nem volt a pályázatba ;) ))
Ha jól tippelek, akkor valahol ez a legszomorúbb része a történetnek... (hogy egy baromi drágán közbe-szerzett de soha nem is használt rendszer beszerzése (csak mert volt rá pénz) miatt szívatnak XD)

(A MAP toolkitjük én az excel táblájuk után nem mertem lefuttatni :))

Hát a postfix soha nem lesz a tulajdona.
Kidobják a Windows-okat is, hiszen az sem a tulajdona? Már ha olvasták az EULA-t. ;)

Hát az IT jogi részét sosem értettem/érdekelt :)

Pedig a Microsoft termékek legszebb része ;)
Ha esetleg van VL szerződésetek akkor szerintem hamarosan gyakorolhatod is mert a távozó ügyfeleket nem szeretik. :)

:)
Itt is olvastam egy licences topik-ot, szórakoztató volt, hogy mindenki máshogy tudta a szent igaz utat. A haverom a T-nél melózik, kértek árat az M$-től egy nagyobb projektre, aztán tököltek egy csomót és újra kértek árat ugyan arra. A termékek ugyan azok az ár meg eljesen más lett, és nem a valuta ingadozás miatt, csak más üzletkötő számolta ki :D

A cégnek igaza van. Értelmes, helyes a policy.

Rövid távon neked szívás (az első általad javasolt verziót javaslom, a régi rendszerből se küldeni, se fogadni ne lehessen, de a TB-vel az elején szívni fogsz, mert hiába tud hatszor annyit, mint az Outlook, másképp néz ki és másképp kell használni, ami miatt mindenki hányni fog). Hosszú távon ha jól felrakod a vírusszűrést, a távollét üzeneteket, az átirányításokat akkor esélyed van egy sokkal jobban menedzselhető rendszerre, amiben hasznos szereped lesz és végül jobban meg fognak becsülni, mint az Exchange időkben.

Az Outlook - TB átálláson még gondolkozom, bár nem nagyon bízom abban, hogy az Outlook 10GB mailbox 100.000 levél méretet megoldja IMAP-on...

Mondjuk újabb Exchange esetében állítható, hogy mennyi legyen cache-elve kliens oldalon. IMAP esetében sem kéne sci-fi-nek lennie (itt nyilván kliens beállítás, GP-ből talán kiszórható), de már rég használtam IMAP-et, nem tudom mi ma a módi.
--
https://naszta.hu

Mi kísérleteztünk egy ideig Outlook kliensekkel IMAP-on, de a kliensek elkezdtek akkora .pst fájlokat produkálni, hogy egyszerűbbnek tűnt elhajítani az összes Outlookot jó messzire. Most egy-egy usernek 5-10 évnyi levelezése elérhető a TB-ben visszamenőleg, nem kell külön archiválni a maileket, minden ott van egy TB archivumban, ami semmiben sem különbözik a többi mappától, csak annyiban, hogy külön van.

Szerintem Outlook - IMAP kombinációt felejtsd el. Valószínűleg nem véletlenül csináltak meg úgy, hogy szar legyen.

Előre leszögezem, hogy tényleg érdekel a válasz, nem ironikus vagy piszkálódó akarok lenni a kérdéssel:

A marketing szövegeken kívül mivel lehet valóban eladni ezeket a szolgáltatásokat ma Magyarországon, vidéken, kis cégnek (mondjuk 2-5-20-50 fiók)?

Tételezzük fel, hogy van szakember, aki tényleg ért az open source rendszer telepítéséhez és üzemeltetéséhez, de a cég nyitott minden megoldásra (nem utasít el elvek alapján semmit, nem fél a felhős adatlopástól, de a saját rendszertől sem), és valamennyi pénzt is szán rá induláskor és menet közben is, nem kell minden ingyen.

Én örülnék pl., ha megszabadulhatnánk néhány levelező rendszer üzemeltetésétől, mert manapság már nagyon macerás/munkaigényes spam szűrőn kívül tartani az elküldött leveleket, és azon belül tartani a bejövő spam-et. De vannak aggályaim (és nem azon, hogy ellopja a felhő szolgáltató az adatot, meg profilt épít, meg ilyenek). Pl.
- ha sok e-mail-be lapolvasás megy a cégnél (vagy bármi más, nagy állomány-csere házon belül), akkor a sok MB-os anyagok mindig mennek egy (vagy több) kört a neten, ahelyett, hogy helyben maradnának? Itt tételezzük fel, hogy a felhasználó nem fog a felhőhöz illő használati mintát felvenni, hanem úgy akarja csinálni, ahogy eddig.
- vagy mi van, ha épp nincs internet elérés (egy nagyobb szervezet bőven levelez annyit házon belül, hogy ez gondot okozzon, nem a kintről jövő levelek miatt aggódok)? Nem lehet mindenhol redundáns internet (vagy technikailag, vagy anyagilag), de ahol van is, sokszor valahol összefutnak a szolgáltatók kábelei (vidéken mindenképp), és elmúlik mind egyszerre adott esetben (két várossal arrébb elmarkolózzák mindenki optikáját - több példa is volt már rá felénk).
- pont O365-tel volt olyan gond, hogy egy addig soha semmire nem használt publikus IP címről nem engedett a webes felületre senkit, és az O365 előfizetés admin sem tudta felvenni az IP-t semmilyen engedélyező listára, csak hosszas nyomozás (a nem releváns hibaüzenetek miatt), majd pár nap átfutással az MS ügyfélszolgálat (és akkor is csak azt a /32-t, nem a tartományt). Ez megint csak plusz munka és idő, amit ugye meg akartunk spórolni.

A "más üzemelteti, neked nincs vele helyben gondod"-on kívül milyen valós tartalom van, ami miatt inkább e felé mozduljunk, ne a saját rendszerek felé? Azért kérdezem itt, mert ahol eddig kérdeztem, csak a marketing szöveget kaptam, és hátha van saját tapasztalat, hogy hosszú távon milyen használni, mik az előnyei.

A felhőre költött marketing milliárdok kezdik éreztetni a hatásuk. Már kollégáktól is hallok olyat, hú az bonyolult, ahhoz csak egy menő felhős cég ért igazán, közben pár évvel ezelőtt napi rendszergazda rutinfeladatokról beszélnek. Ha jól emlékszem 2 évvel ezelőtt egy Microsoft rendezvényen ami rendszergazdáknak szólt, gondolom tévedésből egy sales tartott előadást a felhőről. Néhány igazán kellemes érve a felhő mellett: ők sokkal jobban értenek mindenhez, a helyi rendszergazda béna és úgy is elbassza a dolgokat. Aztán jött a csúcs érve, a rendszergazda gonosz, lop, csal hazudik, ők meg nem. Kis híján lincselés lett a vége.
Nem a felhő ellen vagyok, de már a rendszergazda démonizálásnál járunk ami nagyon gáz.
A kedvenc érvem a felhő mellett, hogy nagyon olcsó. Hát nem az. Ügyfél jött azzal, hogy rádumálták a felhős storage használatra, videókat tárolt ott. Egy gyenge pillanatában fogott egy kockás papírt és kiszámolta, hogy a nem is üzletileg kritikus archivált videótárolás évi 400.000-be kerül. Akkor váltottak Synology storege-ra.
Nem azt mondom, hogy a felhős szolgáltatások rosszak, de a marketing egy kissé túltolja szerintem a dolgot.

Mindekozben evi 600 EUR-bol korlatlan g suite business elofizud lehet de gyakorlatilag 1 usernel sincs hard limit...

Olcsó a felhő, ja. A post példája: https://gsuite.google.com/pricing.html oldal alapján 12 USD / user / hó, vagyis 2400 USD havonta, 28800 USD évente. Az még gombócból is sok.

--
Desktop: Windows10 | Server: CentOS

Az ne zavarjon meg ,hogy en a 400K HUF-os valoszinuleg korlatos tarhelyet kivalto peldara reflektaltam. Ahhoz kepest egy g suite tarhely maga a csoda.

Mikor sales-es Microsoft ember áll ki előadni, azt érdemes helyén kezelni. Ne felejtsd, a MSFT magyarország kft-nek nagyjából csak sales irodája van a graphisoft parkban, technikai emberük már szinte mind elment v. kirúgták őket.
--

Yay, eggyel kevesebb winmail.dat-os (biztos baromi nehéz beállítani az exchanget, hogy legalább az internet felé ne úgy szorja a szemetet (aztán meg sírnak persze, hogy nem megy át a levél / nem tudják megnyitni) :))

Én egy lépésben csinálnám meg a migrálást, mivel a cégen belüli levelezést elég nehéz megoldani ha két helyen van ugyanaz a domained és tisztább is a folyamat.
Első körben én a webmail-re koncentrálnék, mivel ahhoz nem kell 150 gépet is be/átállítani, így mindenki egy webmail... illetve régiwebmai... domain-en elérné az új és a régi leveleit (a régi leveleknél webmail-en kívül lezárnék minden más hozzáférést, hogy ne legyen kavarodás).
Utána van idő a desktop kliensek átkonfigurálására.

A levelek migrálására létezik a fetchmail, ami elvileg áthoz minden régi levelet az új postafiókba.

Az új szervert docker alatt oldanám meg, mivel jóval dinamikusabb a karbantartása, pl itt egy jól összerakott szerver:
https://github.com/hardware/mailserver

Mi postfix/dovecot szerver cserét és postfix/courier->postfix/dovecot átállást (FreeBSD, Linux különböző kombinációkban) csináltunk párat az elmúlt években (volt FreeBSD postfix/courier POP3->Zentyal 6.0 átállás is, ahol az új szerver AD-ként is funkcionált). Annyiban lehet releváns a tapasztalatom, hogy ha az Exchange IMAP-on kiszolgál, akkor eléggé hasonló a migrációs lehetőség, mint Linux/BSD alapról.

Mi mindig úgy csináltuk, hogy az új szerver felállítása és tesztelése után megkapta a bejövő levél forgalmat, és a felhasználók webmail-en elérhették azonnal az új leveleket. A régi szerver onnantól read-only volt akár webmail akár desktop kliens irányából.

A meglévő leveleket attól függően kezeltük, hogy
- ha addig POP3 volt és a desktopon gyűlt minden, akkor az IMAP fiókot felvettük a kliensbe, és bemásoltuk a leveleket, majd töröltük az eredeti POP3 verziót,
- ha IMAP volt, akkor imapsync-kel közvetlen a szerverek között ment a másolás, és "egyszer csak" látta a webmail-en a felhasználó az összes levelét (ebben az a jó, hogy a látott, timestamp, stb. IMAP flag-ek megmaradnak).
Mindkettő időigényes, ha a felhasználók GB-os vagy akár több 10 GB-os levelezést halmoztak fel (mert ugye az e-mail a dokumentumtár/iktatás is egyben, és hátha egyszer kell még az a spam-nak tűnő levél vagy az az akciós újság ami 1 hétig érvényes...).

A klienseket pedig a postafiók migráció közben vagy után állítottuk át az új szerverre (ha pl. imapsync megy, akkor közben gond nélkül lehet az érintett klienseken a fiókot cserélni a várakozási időben).
Kliens cserénél arra figyelj, hogy a legtöbb ember nem épít címjegyzéket (lokálisat sem, nemhogy közöset), hanem a levelező kliens automatikus kiegészítés szolgáltatására alapoz. Új kliens esetén, címjegyzék hiányában (0 tételt migráltál) egy e-mail sem lesz meg. Aztán mehet a magyarázkodás, hogy nem te migráltál rosszul, hanem a felhasználó használta eddig is rosszul a klienst. Utána meg az Outlook automata javítás gyorsár állmány->Thunderbird address book konverzió gúglizás (van ilyen egyébként :-)...
A másik, hogy aki Outlook-hoz szokott, az mindenre köpköd, mert máshogy néz ki. Akkor is, ha életében csak az új levél gombot használta, semmi mást.
Emiatt előre meg kell állapodni, milyen kliens legyen, és ragaszkodj hozzá, hogy egyforma legyen minden gépen, ne választhasson a felhasználó. Volt olyan cégünk 120 fiókkal, ahol a helyi IT azt mondta, hogy a szokások felmérése után abban maradtak a vezetéssel, hogy csak webmail lesz, megfelelő plugin-ekkel, és desktop kliens semmiféle senkinél. Volt hiszti, de megszokták, és azóta az IT-nek sokkal kevesebb a gondja ilyen téren. Máshol mi álltunk át TB-re, mert ősrégi Outlook-ok voltak (amit sóherségből nem akartak frissebbre cserélni), amik folyton belefordultak a PST 2 GB-os limitbe (a felhasználót meg nem érdekelte, hogyan lehetne ezt elkerülni).

Mi jellemzően "hosszú hétvégésen" (pénteken munkaidő végétől vasárnap estig) vállalunk ilyesmit, ami a cégek túlnyomó részénél nem munkaidő, így nem hiányzik a levelezés annyira. Ezen felül mindig állítunk be backup MX-et az egész művelet előtt, hogy ha bármi félre megy a szerver-váltás során, levelek ne vesszenek el. A backup MX-et aztán van aki megtartja szolgáltatásként, van aki nem kéri tovább.

Én nem javaslom a postafiókonkénti átállást plusz proxy-val meg kétfelé irányított egyetlen tartománnyal, irtózat macera lenne ennyi fióknál (is meg kevésnél is). Ha többen csináljátok, egyeztetni kell ki hol tart, ha meg egyedül csinálod, sose fogy el. Tényleg úgy lehet a legmagasabb a rendelkezésre állás, de meg kell fontolni, ér-e annyit. Ezt pedig úgy lehet, hogy ezt a verziót úgy kell beárazni, hogy ha ezt választják, akkor tényleg nektek is megérje, ne csak az ügyfélnek.

A cégnek meg kell értenie, hogy ez egy nagy munka és sok idő. Nem szabad azt engedni, hogy az ügyfél diktáljon minden paramétert, mert abból úgy is teljesíthetetlen dolog jön ki és csak a rossz szájíz marad a végén (legyen ingyen az sw, munkadíj minimális, 0 perc kiesés, senkit ne zavarj a munkában, de délután/hétvégén nem tudunk beengedni, stb.). Ha árérzékeny, akkor nem tudsz kellő számú embert bevonni az egy napon belüli migrációhoz, ha meg nincs elég embered, akkor túl szűk a határidő.
Azt is meg kell érteni, hogy a munkadíj komoly egy ilyen manővernél. Max. a licenc költség spórolható meg, de attól még a feladat komoly, ami nem olcsó. Sokan azt is hiszik, hogy az "ingyenes" szoftvert ingyenesen (de legalábbis sokkal-sokkal olcsóbban) is telepíti/üzemeli be a hozzá értő szakember - pedig ezt nem szabad, a tudás az igazi érték. Nem véletlen, hogy a felhős szolgáltatók azzal érvelnek (jogosan), hogy oké, hogy ingyen van a szoftver, de mibe kerül a szakember, aki telepíti és üzemelteti.

A legtöbben ragaszkodnak hozzá, hogy nem lehet szolgáltatás kiesés, de valójában az üzletmenet elbírna akár napokat is, csak a felhasználók túlgondolják/túlértékelik. A másik, amit meg kell érteniük az elején, hogy az e-mail nem egy garantált szolgáltatás, így "akárhol" is elakadhat a levél attól függetlenül, hogy épp migráció van vagy normál működés. Sokan azt hiszik, az e-mail egy azonnali és garantált szolgáltatás, csupán arra alapozva, hogy a legtöbb esetben nagyjából azonnal megkapják, amit a másik fél küld, és azt hiszik emiatt, hogy ez az alap, ami nem ilyen, az hibásan működik.

Köszi az értékes hozzászólást és, hogy ennyi időt szántál rá.

Szia !

Esetleg Zimbra ?

Nézz utána, szerintem megéri, és nem kell kézzel a Postfix + DoveCot + mySQL + akármit kézzel hegeszteni. Van egy kellemes webes admin felülete,- amihez nem elég, ahhoz aott van a CLI.
Én személy szerint nem használtam de van Exchange/PST (32/64 bit) áttelepítési varázsló.

A community verziót használtuk éveken keresztül, tök jó volt- legalább is nekem bejött.

Mi tesztként telepítettünk egyet egy ügyfélnek és valami apró hiba és az upgrade komplikációja miatt, inkább átvittük volna a jól megszokott postfix+dovecot rendszerbe, de nagyon nem volt egyszerű.
Csilivili rendszer, de ha bele kell nyúlni, akkor problémás, mint általában a csilivili rendszerek (pl. exchange)

Persze, mindennel lehetnek problémák,minél bonyolultabb egy rendszer annál nehezebb belenyúlni Egyébként elég jól vannak dokumentálva a dolgok.
Én régóta használom megelégedéssel, szerintem egy próbát mindenképp megér.

Ezzel egyet kell értenem. Nekünk is van Zimbra egy ügyfélnél, egy másik IT ajánlására került oda régebben.
Nagyon frankó, tényleg mindent csinál, alapjában véve jól működik és nincs vele bak. De tényleg pont olyan, mint az Exchange: csak úgy és csak azt lehet benne/vele elvégezni, amit és ahogy a fejlesztők gondolták. Az üzemeltetőnek gyakorlatilag meg van kötve minden téren a keze.

Pl. hiába open source az IMAP szervere, eléggé sajátságosan valami GUID-del nevezi el az egyes leveleket és valami hash alapján előállított mappákba/almappákba rendezi (ami semmilyen emberi módon átlátható összefüggésben nincs sem a user-rel, sem a user saját mappa-szerkezetével), és csak a saját adatbázisában van meg a hash/guid -> levél és mappája megfeleltetés. Tehát pl. mentésből szeretnék egy levelet kivenni -> a teljes rendszert vissza kell állítanom, és a gyári módon kikeresni azt a levelet. Ez sima postfix/dovecot esetében azért nagyságrendekkel könnyebb művelet.

Szóval a Zimbrát csak alapos tanulmányozás, teszt rendszer beüzemelése, használata és a várható műveletek (backup, DR, egyedi kérések amik eddig is előfordultak) tesztek elvégzése után javaslom magam is.

Pont ezért nincs terveben. Biztos jó, de annyira egyszerűek az igények, hogy fölöslegesen bonyolult lenne. Meg végre rendesen kitanulom a postfix-et :)

Alap install baromi gyors, egy csomó mindent összekattintgat az ember, a többire meg cli.

Ha egyszerűek az igények, egyszerű install.

Ui.: nem akarok mindenáron kardoskodni a Zimbra mellett, csak tényleg egy open source elemekből összerakott jó megoldás.
Ui 2..: webes kliens is nagyon jó, én is azt használom.

"Szóval a Zimbrát csak alapos tanulmányozás, teszt rendszer beüzemelése, használata és a várható műveletek (backup, DR, egyedi kérések amik eddig is előfordultak) tesztek elvégzése után javaslom magam is."

+1, de mindig lesz olyan ami még nem volt. Ha fizetős akkor ott a support, ha nem akkor communityben nagyon jó a fórum.

En amikor migraltam akkor .pst-bol gyartottam maildirt es azt etettem meg.

Nalam az AD is borult (egy szerveren volt az exchange es ad), igy macerasabb volt ujraepitgetni a windowst, mint attenni a leveleket.

Probaltam outlookkal is szinkronizalni, de teljesen megbizhatatlan. Allandoan kiakadt olyan kicsi postafioknal is amiben mindosszesen csak 30-35GiB level volt. De volt, hogy meg a 15GiB-os postafiok szinkronizalasanal is beakadt tobb napra.

En readpst-t hasznaltam maildirba konverziora es mbsync-kel felszinkronizaltam (egyszer se akadt ki).

Ezt egy dockerba betettem es migracio utan archivaltam a komplett kontenert, majd egy ev mulva toroltem

Azt nem vagom, hogy miert ne lehetne egy atmeneti idoszak ahol az outlookban mindket postafiok benn lenne (regi, uj). Ha meg el a regi szerver.

Ja, en a naptarat es cimjegyzeket is csinaltam/migraltam.

Most a szerver oldal teljesen linux alapu (AD, level), a kliens meg teljesen windows+apple+android.

A naptarat hasznaljak, de a cimjegyzek szerintem tok felesleges.

Inkabb kellene egy ceges telefonkonyv (weboldal), ahol a user utananezhetne. Csak ugye azt karban kell tartani, arra meg embert kene kijelolni. (meg igazabol van is, csak mindenki readonly, szerkeszteni meg senki se akarja mert az az "ove", nem ossza meg. Persze telefonjan ott a viber, messenger, stb)

Szoval a cimjegyzekre meg jo megoldast nem talaltam ki...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"de a cimjegyzek szerintem tok felesleges" pedig egy jol mukodo GAL az nagy josag

global address list-re gondolsz gondolom.

Ez inkabb human problema mint technikai. Nalunk akar carddavval le lehet szinkronizalni mobilra (android, ios).
Van weboldal nezete is.

De mit er az egesz ha nem egyertelmu, hogy kinek kellene karbantartani?

Ez nem informatikai problema.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A GAL lista nalunk AD-bol jon es termeszetesen a HR tartja karban hiszen nekik kell tudni ki hol dolgozik a cegnel es milyen modon lehet oket elerni.

> termeszetesen a HR tartja karban

Te csak egy ceges telefonkonyvrol beszelsz, ahol tudjak, hogy melyik kolleganak mi az emailcime/telefonszama.

En pedig egy ceges partneri telefonkonyvrol es emailcimekrol beszelek, ami a mi esetunkben olyan 4000-4500 cimet jelent. Es egyik teruletnek sincs meg igazan a felelose, hogy up-to-date tartsa.

A ceges telefonkonyvet toknek szinkronizalnek le egy mobilra egyebkent.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem kell syncelni. Eleg ha keresni tudsz benne. Es sokszor hasznos ha kollegat kell hivni mert mondjuk honnan tudod fejbol a szamat?

Amugy meg sajat cimlistat amit a user felvesz az adott accountra nem latja?
Ez azert eleg alap dolog. Mondjuk ezt miert kene kozosen latniuk?

Milyen partnerek azok akiknek a cimeit akarod latni de nincs karbantartva? Ez azert eleg WTF kategoria.

amiket irsz, ahhoz nem kell caldav.
Ahhoz egy kutya kozonseges weboldal is eleg, ha van aki karbantartja (te esetedben hr).

Ha ADben aksrod karbantartani, akkor egy tok egyszeru export szkriptel kinyomod az erdekes mezoket (nev, telszam) egy txtbe, amit egy weboldal kiir (napi egyszer cronbol frissit)
Ehhez se kell caldav.

Caldav ahhoz kell, hogyha mobilon *es* outlookban is szeretned latni a cimeket.

Ha csak outlookot hasznal az illeto, akkor az outlook beepitett kiegeszitojet hasznalja, es arra se veszi a faradtsagot, hogy address bookba tegye az illetot.
Ehhez se kell caldav.

Kicsit tul van misztifikalva ez az egesz, meg ha megfeszulsz se ugy fogjak hasznalni, ahogy te elkepzeled.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A naptárat mivel oldottad meg?

caldav szerver. Outlookban meg van caldav plugin.

Van fizetos is, meg van ez az ingyenes:
http://caldavsynchronizer.org/

A fizetos meg ez:
https://hu.evomailserver.com/download.php

A fizetossel az a problema, hogy valtoztattak valamit, es azota a kozos naptaraknal ha modositasz; kepes egy ugyanolyan nevu lokalis valtozatot letrehozni, igy egy event 2x lesz meg mas idopontban. Igy most ebbol a regebbi plugint hasznaljuk, ahol meg lehet a githubost. Az kb. egy eve megy. De nemelyik windowsnal hibaval kilep.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....