Exchange adatok mentése

Microsoft Windows

Hello,

ötleteket kérnék, hogy hogy lehet jól és hatékonyan exchange postafiókokat lementeni backup céljából.
Először simán differenciális backupot állítottam, de mivel egy nagy fájlban tárolja az összes infót, nem hatékony, rohadt sokáig tart a mentés, megeszi a helyet, és visszaállítani sem lehet, mert ugye csak egy-az-egyben lehet mindent, az összes fiókot.
Aztán keresgettem, powershellbe van a new-mailboxexportrequest. Ez meg amellett hogy teljesen megeszi a gépet (amíg megy a backup, teljesen használhatatlan) megbízhatatlan is, mert a 10-ből random néhány postafiók (2-3, de van hogy 5) failed.

SBS 2011 egyébként.

Kösz

  • 22050 megtekintés

( barang | 2012. 11. 25., v – 19:29 )

Szeva,

Én Backup-Exec -et használok.

Pont az enterprise-nak nincs szüksége rá, mert már van egy enterprise backup rendszere, ami már kezeli a problémát, és elmebajt kapnának, ha egy idegen szoftvert kellene integrálni a meglévő rendszerükbe.

Leginkább az otthoni/SBS felhasználóknak kell az önhordó rendszer.

Enterprise környezetben általában külön beszállító viszi a saját termékét, vagy általa megbízhatónak véltet, felelősségvállalással, kompetenciával, szakértelemmel(jó esetben), supporttal(a gyártó felé is), és fel sem merülnek ilyen dolgok például mailbox mentése szintjén.
Nem alázás miatt írtam, de egy enterprise-ot ne keverjünk egy kkv-soho szintjére, ott igenis értékes adat a mentés, jellemzően nem viccelik el.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( Croc | 2012. 11. 25., v – 19:42 )

Szerintem is más, nem MS termékkel lehet normálisan menteni win2k8-tól és felfelé az Exchange-et. Annó win2k3 környéként még egész használható volt ilyenre az ntbackup, de ez az új mentési megoldás... elönyét még nem láttam...

Egyébként jobb híján nézd meg az exmerge-t. PST-be lehet kiexportálni a postafiókokat. Parancssorból is paraméterezhető. Szükség esetén így könnyen megnyitható a lementett postafiók akár kliens oldalon is. Igaz nem a legjobb, de jobb mint a semmi :)

Igen, ntbackupot én is szerettem, sajnos 2k8-tól felfele már nincs a rendszerbe. A beépített Windows Backupot én se szeretem. Cobian BAckupra találtam rá pár hónapja, szeretem, tetszik, okos. Ezt használom mostanába winen. De egyébként ha lenne ntbackup se lennék vele előrébb, mivel az is fájlszinten mentené, és hiába allítasz be inkrementális, differenciális vagy akármilyen módszert, mivel egy nagy fájl az exchange összes szarja, értelemszerűen mindig változik, szóval minden nap egy 20G-s "differencia" lenne, ami maga a fájl. (és persze ebből a visszaállítás ugyanúgy problémás).
Ez a powershelles mailboxexport is pst-be mentené a cuccot, ha működne stabilan....
A mentést meg mindenképp szerver oldalon kell megoldani. Nem bohóckodunk klienseken, meg egyébként is nehezen kivitelezhető, nyűgös, stb...
A legjobb az lenne, ha úgy mint linuxon, a maildirekre lehetne nyomni egy rdiff-backupot, aztán viszlát. :) De hát álmodik a nyomor...
--
Discover It - Have a lot of fun!

" mivel egy nagy fájl az exchange összes szarja, értelemszerűen mindig változik, szóval minden nap egy 20G-s "differencia" lenne, ami maga a fájl"

Nos, a win2k8 beépített Windows Backupja blokk szintű inkrementális mentést csinál, ezért csak a ténylegesen változott blokkok mérete lesz a napi mentés.
Ez mondjuk akkor működik csak, ha egy teljes diszket adsz a mentésnek (pl. egy külső USB diszket.)

Ha fájlrendszeren levő könyvtárba (vagy network share-re) mentesz, akkor csak teljes mentést tud.

Lehet, hogy egyszerű mint a faék, viszont a semminél jobb, és működik. (Már sikerült belőle helyreállítanom elfüstölt Exchange szervert új vasra)

( hnsz2002 v | 2012. 11. 25., v – 20:27 )

Attól függetlenül, hogy nem megbízható ez a mailboxexportrequest:
Írtam egy scriptet, ami a mentést csinálná, amit ha én lefutattatok tökéletesen működik, ha berakom ütemezett feladatként és beállítom hogy az én userremmel fusson, akkor nem jó... Fingom sincs miért. Idióta az egész.
--
Discover It - Have a lot of fun!

( joco01 v | 2012. 11. 25., v – 20:35 )

Szerintem:
1. Microsoft DPM über alles
2. Utánzod a DPM-et: összetákolsz valami programot, ami shadow copy-t készít az Exchange VSS writerrel, és kimásolod a nyers adatfájlokat.

--

A VSS garantáltan konzisztens snapshotot készít. Ha bármilyen mentés ezt nem használja, akkor az olyan, mintha menet közben kirántanád az Exchange alól a diszket, tehát nem egy életbiztosítás, habár valószínűleg erre fel van készítve. A DPM azért jó, mert mindent megcsinál helyetted, képes mailbox szintű visszaállításra is, konzisztencia ellenőrzést futtat a mentésen, inkrementális, stb. Nekünk tökéletesen bevált.

--

( legyes | 2012. 11. 26., h – 10:16 )

Nálunk a DPM nagyon nem vált be, száműztük "Elba szigetére". Áttértünk az ESXi 5.1-re virtuálizált zixcséndzsre és a snapshotos megoldással online kiszedjük alóla a virtuális HDD-t. "Bare metal" mentés, ingyen.
Azért is jobb virtuálizálva, mert úgy jobban gátat lehet szabni annak, hogy egy 64 processzoros, 32 TB RAM-ot is képes kifektetni 60 postafiók. De pont ugyanolyan sebességgel megy 1 magon és 4G RAM-on virtuálizálva :)

Ezt javaslom áttanulmányozni: Understanding Exchange 2010 Virtualization

Például ilyesmi olvasható benne:
"Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it's running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported."

Üdv,
Marci

meg kb. semmit nem érdemes snapshot-al menteni, ami inkonzisztens lehet, ha nincs rendesen sync-elve/tranzakció lezárva snapshot előtt.
Egyébként erre vannak megoldások,google kulcsszó: quiesce.
A legtöbb windows mentő kliens is snapshot alapon dolgozik (windows shadow copy) csak snapshot előtt konzisztens állapotba hozza a rendszert.

( hnsz2002 v | 2012. 11. 26., h – 23:12 )

Ilyenkor hol van a sok okos ms marketinges?
Mellesleg 8GB rammal olyan ki**szott lassú az egész rendszer, hogy mindjárt felvágom az ereimet. Nem tudom eldönteni sokszor hogy kattintottam vagy csak akartam, mert semmi reakció nincs. Ezt még megkoronázza a csodás T-s net feltöltési sebessége is. Tiszta élmény.
--
Discover It - Have a lot of fun!

Előre mondom: nem vagyok marketinges, nem dolgozom sem az MS-nél.
Talán kezdd el monitorozni a szervert, hogy miért lassú és ne az ereid vágd fel. Továbbá SBS-t vett az ügyfél, ami csak ezt tudja. Az SBS egyáltalán nem enterprise, hanem small business megoldás. Megszoksz vagy megszöksz...
Mindenképp egy másik programra lesz szükséged a normális mentéshez. Ingyenes programról viszont nem tudok.

Mert megette a memoriat, nincs szabad memoria, azert. Az eg vilagon semmi extra nem fut a gepen ami nem az alap sbs resze. Egy sql express, ebbe van az ugyviteli szoftveruk adatbazisa (kb. 50MB), meg fut rajta egy dns updatelo kliens (50kB). Az AD tartomany van ugye, az exchange van hasznalva kliensen outlookbol, meg nehany megosztas van. Semmi mas szolgaltatas nincs hasznalva, se sharepoint, se iis, se rdp, se semmi. Es mindezt csucsterhelesen 7-8 user hasznalja.
A vicc az, hogy ugy kerte az ugyfel a szervert, hogy 4G rammal. En mondtam, hogy az keves lesz nagyon, legyen mar 8G... De ahogy elnezem ahhoz hogy normalisan menjen, legalabb 12, de inkabb 16G kene.
Az meg hogy sbs vagy sem, tok mindegy, az exchange ugyanaz benne, mint amit kulon megvehetsz es felrakhatsz akarhova, egy standardra is. Szoval ha itt nem megy a mailbox export, akkor mashol sem.
--
Discover It - Have a lot of fun!

Ugye a szabad memória alatt nem azt érted, amit a feladatkezelő mutat?

Az SBS-ről igaz, amit írsz, viszont én azért hoztam fel, mert az SBS egy "minden egyben, egyszerűen és olcsón megoldás kisvállalatoknak". Ha MS-os eszközökben gondolkodunk, akkor körbe kell nézni a System Center termékcsaládban, ott is konkrétan a DPM-ről beszélek. Persze, ez fizetős, nincs benne az SBS-ben.

Csak mert több tényezőtől függ, hogy mennyibe is kerül - licencekonstrukció, kedvezmények, beszerzési forrás stb. Googlebe beírva a Microsoft System Center Data Protection Manager Server ML Enterprise 2010 SNGL OLP C verzió 152e+áfa áron kapható. A Microsoft System Center Data Protection Manager Server ML Standard 2010 SNGL OLP C verzió 56e+áfa. Ez például Open Licence, OVS vagy OV keretében nyilván más az ára. SA előfizetés is ugyanígy befolyásolja az árat. Kell hozzá a kliens licence is, ami kb 12-13e Ft körül van.

Ha azt nézzük, hogy kb 1-2 óra alatt telepíthető, és megcsinálható vele egy kisebb cég teljes mentése, akkor tényleg aprópénz.
File servert, exchange szervert és kb. 60-70 MsSQL adatbázist mentek vele. Nem kellett sokat tökölni a telepítéssel, egyszerű mint a faék, és eddig mindíg sikerült visszaállítani amit esetleg kellett.

Összehasonlítva egy komolyabb mentő cuccal, a DPM lófütty, de az ára is töredéke.
Ha arról van szó, inkább fizetek egy ilyen cuccért és hulladék idő alatt kész a működő mentés, mint ingyenes akármikkel elkezdjek 1-2 napot barkácsolni, és a hiba tuti akkor fog előjönni, amikor a legjobban fáj.

en is jobban bizom a kereskedelmi mentoszoftverekben. De a topiknyitot arrol gyozkodtem, hogy ahelyett, hogy kinlodna a mentessel, ami neki (eddig meg) nem jott ossze, inkabb archivalja a leveleket. Meg van a mentes jogosultsaga is (nem vonom ketsegbe a DPM ugyesseget), de ez nem az a liga, amiben az archivalo megoldasok fociznak.

Matolcsy ur, mondjon mar le!

Mondasz olyat, amihez képest a DPM lófütty? Nem vagyok egy nagy sysadmin mágus, amikor nekünk kellett mentés, nem néztünk nagyon utána, a DPM egyértelmű választásnak tűnt, és nekem ez is elég komolynak tűnik, de legalábbis bőven kielégíti az igényeinket, és még attól is többet.

--

pl. TSM (Tivoli Storage Manager)
vagy EMC Networker (lánykori nevén Legato Networker)
esetleg Symantec Netbackup (lánykori nevén Veritas Netbackup)

De más pályán fociznak mint a DPM.

DPM teljesen elég pár gépes környezetbe, nem nagyon ismerem hogyan skálázódik, de 20-30 gépnél többet nem mentenék vele.

A fentiek jól boldogulnak több száz, vagy 1000+ gépes környezetben is (csak győzze az ember a vasat alájuk tolni.)

Mert a Windows Server gyorsítótárnak használja a szabad memóriát - Linuxhoz hasonlóan. Trolloknak: "hasonlóan"-t írtam, nem "megegyezően".
A Resource Monitor segítségével tudod korrekten megmondani, hogy mennyi is a tényleg felhasznált memória. Nagyon leegyszerűsítve 22 MB-ot jelöl szabadnak, 199 MB-ot elérhetőnek (kb. szabad + még felszabadítható összege - nem lapozható), 176 MB-ot lemez cache-nek. Gyakorlatilag 199 MB-tal tud gazdálkodni a rendszer a fizikai memóriában, a virtuálisban már ~4,2 GB-tal. Dobj még a szerverbe 8 GB memóriát és meglódul.
A baj az, hogy nincs igazán lemez cache-d. Így ne csodálkozz, ha dög lassú a rendszer - a proci se tudja kifutni magát, állandóan a laphibákkal foglalkozik - kapcsold csak be View/Show kernel times opciót.
Ha a téma mélyebben érdekel: http://www.mit.bme.hu/system/files/oktatas/targyak/8372/slides_18_windo…

"Mert a Windows Server gyorsítótárnak használja a szabad memóriát"
Persze, ez nyilvánvaló. És nem is az a problémám, hogy mittomén 8G ramból 2G cached, hanem hogy 176MB, és összesen 200MB van, ami gyakorlatilag semmi.
"Dobj még a szerverbe 8 GB memóriát és meglódul. A baj az, hogy nincs igazán lemez cache-d."
Tehát te is azt mondod, hogy kevés a ram. Akkor miről beszélünk?
--
Discover It - Have a lot of fun!

Szia!

Megnézted már, hogy a MS mennyi memóriát ajánl minimum egy SBS 2011 alá? Remélem nem úgy adtátok el egy ügyfélnek, hogy ti sem vagytok vele tisztában.
Minimum 8GB, de inkább 10, maximum 32. Ha épphogy teljesíted a minimumot, akkor ne várj a rendszertől túl sokat.

Szia,
Imi

( sj | 2012. 11. 27., k – 09:44 )

nem pontosan mentes, hanem archivalas (ez amugy sokkal tobb, mint a mentes), akkor probald ki a piler-t, ami minden ki/beerkezo levelrol eltesz egy masolatot, igy minden mailbox minden levele megvan az archivalo gepen.

Ja, es a piler-hez van egy export utility, ami EML formatumban kiirja a kivant leveleket, igy arra is lehetoseg van, hogy pl. az yyyy.mm.dd. nap osszes levelet kitold egy konyvtarba, amit aztan eltehetsz, ahova akarod.

A piler a mar meglevo leveleket le tudja szedni az exchange-rol imap-pal, de tud pst-t is importalni.

Reszletek: http://www.mailpiler.org/en/index.html

Matolcsy ur, mondjon mar le!

nem nagyon akarok pusztán jótékonyságból ilyet adni nekik

siman el tudom kepzelni, mint erteknovelt szolgaltatast (foleg, hogy a backup mellett sok egyeb erenye is van). Egy kis brazil isp konkretan ilyen megfontolasbol teszteli a pilert. Ha meg ki tudsz ezert sajtolni egy kis zset beloluk, akkor ...

A backupok meg egy netgear NAS-ra mennek (mennének...).

hat, vegul is izzadhatsz tovabb a jelenlegi (nem) megoldassal. Ha sikerult, akkor ird meg a tapasztalataidat, erdekel, hogy exchange alatt milyen lehetosegeket talalsz. Ha viszont muszaj nekik valamilyen backup-ot nyujtani, es nem talalsz megfelelo megoldast, akkor szivesen segitek egy email archivalo megoldas osszepatkolasan. Szerintem megeri.

Matolcsy ur, mondjon mar le!

Nos, feladom.
Ezt próbáltam még: http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/9d…
Lentebb venni a párhuzamos exportálásokat. Levettem 1-re, így már "jobb" a helyzet, mert csak 2 mailbox exportja failed. A vicc továbbra is az, hogy ha külön kérek egy exportot az egyik ilyen mailboxra, akkor előfordul hogy jól lefut.

De összességében még mindig katasztrófa és csőd.
--
Discover It - Have a lot of fun!

Hali,

Mailt nem olvasol?

Ahogy irtam csinalj egy uj usert teljes preview joggal az osszes felhasznalo inboxra (vagy amit menteni akarsz inbox/sent items, calendar etc...).
Az uj felhasznalo outlookjaban pedig hozd letre az osszes felhasznalot ahogy a szerveren van es csinalj egy szurot, hogy dobalja szet a leveleket a felhasznalok cime alapjan.
Ezzel meg lesz az osszes level szetvalogatva egy kliensen, amit barmikor vissza lehet allitani, ha kell.

A klieneseket pedig ugy allitsd be, hogy local pst file legyen es szedd le a leveleket a szerverrol, hogy csak a klienseken legyen.
Ezzel felszabaditod az eroforrasokat a szerveren. Nyilvan a kliens gepet ahova a levelek omlesztve mennek menteni kell.
Csak itt lesznek meg a levelek, ha barmelyik felhasznalo gepeben lehal a HDD. Jelenleg 50GB a limit az ost filera szoval van eleg hely menteni, meg szet is lehet szedni akar minden felhasznalora kulon pst file.

Persze nem fontos leszedni a leveleket a szerverrol lehet ott is tarolni, csak az kinyirja az eroforrasokat ahogy emlitetted te is.

http://office.microsoft.com/en-gb/outlook-help/manage-another-person-s-…

Ahogy lesz idom kiprobalom es referalok.
Elvileg mukodnie kell. Migraciohoz hasznaltam, mert az exmerge es egyeb kacatok nem mukodtek rendesen nekem sem.

Egeszen biztos vagy abban hogy egy beallitas az egyenlo a hackelessel?
Ez egy beallithato opcio a kliensen, nem a registryben irsz at valamit.

Amugy elolvastam a piler-t, hat inkabb azt neveznem hacknek es nem ezt.
Ez Microsoft altal tamogatott opcio, piler nem az.

http://support.microsoft.com/kb/287070

De igen olvasok, válaszoltam is.

A levelek letöltése biztosan nem járható út, mert másik outlookból (notebook), mobil kütyükről, vagy akár owa-ról is el kell érni őket. Szóval én ezt a pop3-as módszert soha sem szerettem, soha nem preferáltam, nem használtam. Mindig IMAP.
--
Discover It - Have a lot of fun!

Bocsi, reggel meg nem lattam, innen meg most nem tudok belepni.

Szoval ez nem pop3, hanem szerver oldali beallitas a user folderre.
Barmit valtoztat a user az pont ugy fog valtozni az extra usernel is.

Nekem jelenleg mukodik exch 2007-el f@szan.

Amugy 1-2 helyen ticketing rendszerben hasznaljak az exchange-nek ezt a betekinto funkciojat.
Olvasd el a linket amit kuldtem, nem is emliti meg a pop3-at.

Szerintem nem valtja ki a piler a backupot a kovetkezok miatt:
- naptar bejegyzeseket, cimjegyeket nem tud menteni, sem uzenet flageket (pl olvasott)
- a cegen belul kuldott leveleket (outlook-exchange-outlook) nem menti
- ha a postafiokbol torlok vagy atmozgatom alkonyvtarba, annak sem lesz nyoma. Nehez lesz meggyozni a felhasznalokat, hogy ujrarendezzek a leveleiket egy visszatoltes utan

Ettol fuggetlenul tetszik az alakalmazas csak nem menetes helyett.

- naptar bejegyzeseket, cimjegyeket nem tud menteni, sem uzenet flageket (pl olvasott)

igaz. A piler csak az emaileket archivalja, pl. a naptarat azt nem

- a cegen belul kuldott leveleket (outlook-exchange-outlook) nem menti

de, menti. Ami erinti az exchange-et, az a journaling segitsegevel atmegy az archivalo gepre is

- ha a postafiokbol torlok vagy atmozgatom alkonyvtarba, annak sem lesz nyoma. Nehez lesz meggyozni a felhasznalokat, hogy ujrarendezzek a leveleiket egy visszatoltes utan

ha a user kitorol egy levelet, az attol meg megmarad az archivumban (pont ez a poen benne). Az is igaz, hogy attol meg, hogy atteszel egy levelet pl. egyik imap mappabol egy masikba, az nem erinti az archivumot. De ha pl. keszitettel magadnak filtereket, stb. a bejovo leveleknek, az visszaallitasnal is mukodni fog. Az meg egy erdekes kerdes, hogy ha pl. elhasal az exchange, es mondjuk from scratch ujra kell huzni, akkor a levelek hany %-at kell az archivumbol visszatolteni.

Matolcsy ur, mondjon mar le!

- a cegen belul kuldott leveleket (outlook-exchange-outlook) nem menti
"de, menti. Ami erinti az exchange-et, az a journaling segitsegevel atmegy az archivalo gepre is"

Sajnos nem talaltam infot errol a doksiban (vagy figyelmetlen voltam), eddig azt hittem, hogy a internet es mail szerver koze ekelodik be.

"ha a user kitorol egy levelet, az attol meg megmarad az archivumban (pont ez a poen benne)."

Szerintem pont ezert nem alkalmas mentes helyett. Ha kapok evi 3000 levelet es ebbol megtartok kb evi 200-at, akkor egy visszatoltes utan nem szeretnem ezt a valogatas/torlest tobb evre visszamenoleg megtenni ujra, az archivumban meg nem szeretnek keresgetni 10k level kozott.

"De ha pl. keszitettel magadnak filtereket, stb. a bejovo leveleknek, az visszaallitasnal is mukodni fog."

Sok esetben nem lehet jo filtereket beallitani pl. projektek alapjan tortenik a csoportositas
De ha a filterek a levelek 90 szazalekat megoldjak es csak a 10 szazalekat kell kezzel atpakolgatni, az akkor is pont 10 szazalekkal tobb mint, ha mentesbol allnal vissza.

"Az meg egy erdekes kerdes, hogy ha pl. elhasal az exchange, es mondjuk from scratch ujra kell huzni, akkor a levelek hany %-at kell az archivumbol visszatolteni."

Szerintem a postafiokja 100%-at. A felhasznalot kezeljuk felnottkent annyira, hogy azokat a leveleket azert tarolta ott - a quotaja erejeig - mert szuksege van ra.

eddig azt hittem, hogy a internet es mail szerver koze ekelodik be.

barhol lehet, teheted akar a felhobe is a cegen kivulre.

Ha kapok evi 3000 levelet es ebbol megtartok kb evi 200-at, akkor egy visszatoltes utan nem szeretnem ezt a valogatas/torlest tobb evre visszamenoleg megtenni ujra, az archivumban meg nem szeretnek keresgetni 10k level kozott.

izles kerdese. Siman realis forgatokonyv az is, hogy ha 0-rol kell visszaallitani a mail szervert, akkor nem akarom sem a 200-at, sem a 3000-et ujra a mailboxomba. Mondjuk azt nem mondtad, hogy a userek levelei megvannak-e a sajat gepukon, de ha igen, akkor folosleges _lehet_ a multat ujra ratolni a mail szerverre.

De igazad van, ebbol a szempontbol nem ekvivalens a mentes es az archivalas. De azt is tegyuk hozza, hogy (ha csak mentesed van, akkor) a hipotetikus exchange lehalas es a legutolso mentes ota jott levelektol igy jo esellyel el lehet bucsuzni.

Az a keresgeles pedig se nem bonyolultabb, se nem tart tovabb, mint ha a lokalis MUA-ban tenned ugyanazt, de mondom, izles kerdese.

az akkor is pont 10 szazalekkal tobb mint, ha mentesbol allnal vissza.

igaz. Felteve, hogy tenyleg van ertelme a mailboxot pontosan ugy visszaallitani.

Szerintem a postafiokja 100%-at. A felhasznalot kezeljuk felnottkent annyira, hogy azokat a leveleket azert tarolta ott - a quotaja erejeig - mert szuksege van ra.

erosen szubjektiv. A felhasznalok felnottkent kezelesevel nincs ok-okozati viszonyban az, hogy minden olyan emailt kitorolnek, ami nem kell nekik. Nekem pl. van egy csomo automatikus ertesitom, amiket nem torlok ki, de nem okozna torest az eletemben, ha egy mailbox visszaallitasnal nem kapnam vissza.

Matolcsy ur, mondjon mar le!

Viszont van nem egy régi levél, amire nem tudod mikor, de szükséged lehet, visszakeresni vagy újra infót előhalászni belőle... Ezekért pedig mindenképpen megéri az összeset visszatenni. Saját magamról is tudom, de akárhol akármelyik usert/céged ha megnézed, még mindig az email az elsődleges és legfontosabb információforrás, információtár, és ezen keresztül osztják meg egymással a cuccaikat (átküldi csatolmányba), sokszor még akkor is, ha van erre samba share vagy egyéb. És ez egy jó darabig még így is fog maradni, hiába a sok megreformálni próbáló újítás (itt lehet gondolni akár a facebook féle összemosásra, egroupware-re, sharepointra vagy bármire). Ha egy user elveszti a mailboxát, az legalább annyira fájdalmas, mintha a táskéd veszted el, benne minden kulcsoddal, igazolványoddal, telefonoddal, stb.
Ami meg nem kell, azt gyorsan ki leher törölni, pl. thunderbirdben nyomsz egy szűrőt a feladó vagy a tárgy alapján, ctrl+a, del, és el is tűntek a régi de esetedben nem kellő értesítő levelek, de a többi megmaradt. :)
--
Discover It - Have a lot of fun!

nem vitatom (sot), hogy az email a legfontosabb csatorna, de pont az a lenyeg, hogy ha meg is hal az exchange, akkor sem veszitetted el a leveleidet, mert ott van mind az archivumban. A dilemma csak az, hogy vajon mindet vissza kell-e tenni az exchange-re vagy sem (ha egyszer megvan a user gepen, es megvan az archivumban is)?

A torles kapcsan valoban ki lehet torolni a mar erdektelen leveleket, de ketlem, hogy ez egy bevett gyakorlat atlagbela kkv/enterprise user reszerol.

Matolcsy ur, mondjon mar le!

( mrceeka v | 2012. 11. 28., sze – 10:13 )

Hello,

Milyen helyzetek kezelésére van szükséged a mailbox szintű visszatöltésre?

Üdv,
Marci

Mondok egy példát. Bizonyos okokból engedélyezve van a POP3. Az ember leszedte POP3-on a leveleit és elfelejtette bekattintani, hogy "egy példány a szerveren marad".

Ha nincs bricklevel mentés, akkor csak az egész Exchange database-t tudod visszaállítani.

Persze lehet azt mondtani, hogy mi a bánatnak akar az ügyfél POP3-at 2012-ben. Én is ezt mondom.

De ha azt akar, akkor azt akar. Persze vissza tudja tuszkolni a leveleit ha akarja. De pl ha azok külön mappákban voltak az Inbox alatt, akkor bizony azt neki kézzel kell szétválogatni.

--
trey @ gépház

Hello,

az Exchange Messaging Records Management képességeit használva beállíthatod, hogy meddig tartsa meg az Exchange a törölt elemeket, amiket helyre tudsz állítani Outlook-kal, MAPI-n keresztül.
http://technet.microsoft.com/en-us/library/bb123507(v=exchg.141).aspx
Annyira igaz ez, hogy nagyvállalati környezetben (itt már nem az SBS-ről beszélünk) backup nélküli Exchange architektúrákat is építenek: http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-…

Üdv,
Marci

[ignagyvállalati környezetben (itt már nem az SBS-ről beszélünk) backup nélküli Exchange architektúrákat is építenek[/i]

mondjuk azert nem kicsit bator...

many enterprise organizations have said goodbye to the high-end SAN and the expensive disks that comes with it, the expensive third party archiving solution, and finally the often expensive disk or tape based backup solution and thereby cut IT costs significantly.

nem tudom, mennyi az a 'many', de nem feltetlen eleg az exchange 2010 archivalasi kepessege, hogy kivaltson egy (expensive) "third party archiving solution"-t. Hogy ez ugyben legyen egy kis kontraszt is, ime egy masik iras:

Is Exchange Server 2010 Archiving a Hit or Miss? http://www.theemailadmin.com/2009/09/is-exchange-server-2010-archiving-…

"We have implemented Exchange 2010 and are very dissapointed with the so called archiving features. We need keep all emails for compliance reasons and simply journaling and keeping them in Exchange had massive performance and backup issues. Also it puts all the onus on IT and
end users to define compliance rules, this will not stand up in any court in the UK if a legal case showed IT were doing the searching or users had deleted some emails etc. No single instance, no fulltext indexing (unless you want more performance issues) - what a let down.
We have now gone for 2e2 SourceOne for our archiving needs after Microsoft themselves told us that for true compliance we need to use a third party solution that can also move archived data to WORM media. Hope this helps anyone thinking of using Exchange for archiving, ask them first and tell them about your needs.
Regards
JS"

Matolcsy ur, mondjon mar le!

Nem egészen: az archiving-nak nincs szerepe a backup nélküli architektúrában.
A beépített legal hold lehetővé teszi a bíróság előtti bizonyítást, a Messaging Records Management pedig a központi policyt, amiket az Általad hivatkozott cikk az archivingtól vár (ami nem tudja, mert nem neki kell tudni)

Üdv,
Marci

ezt olloztam ki a cikkbol, amit bedobtal:

many enterprise organizations have said goodbye [...] to the expensive third party archiving solution, [...] thereby cut IT costs significantly.

Meg az derul ki, hogy mivel az exchange 2010 akkora spiler, ezert sok ceg megszabadult a draga san, mento ill. archivalo rendszerektol is. En ebbol egyet ragadtam ki, az archivalast, mivel en ebben utazom, es ellenvelemenykent ideztem egy UK(?) user/admin velemenyet, hogy biztos jo az exchange 2010, de nem eszik olyan forron azt a kasat...

Matolcsy ur, mondjon mar le!

Igaz amit írsz, ha van hely. De azért jócskán akad még ilyen-olyan okból régi Exchange, KKV egy géppel, meg olyan Exchange is, ahol a 75GB-os Store limit kemény probléma. Ilyenkor a retention időt az ember kicsire veszi (vagy 0-ra), mert azon zsonglőrködik, hogy a rendszer működjön. Ha a Store eléri a limitet, akkor pedig tudjuk mit csinál (leállogat).

Értem én, hogy ez nem a Microsoft problémája. Viszont azt nem lehet vitatni, hogy a bricklevel mentésnek van létjogosultsága ilyen-olyan körülmények között.

--
trey @ gépház

És mi van akkor, ha a vas hal ki alatta? Vagy elviszi az egész vasat a Sandy hurrikán? :) Értem én hogy nagyvállalatoknál nem egy, nem két exch server van, de kicsibe ez olyan félmegoldás, hogy van is meg nincs is backup.
Ráadásul ha fizikailag gondolom ez is ugyanabba a nagy blob db-ben van, mint a többi adat. Tehát ha ez sérül, akkor a "backup" is sérül, ha a hibás részeket is lereplikálja.
--
Discover It - Have a lot of fun!

Ha a vas hal ki alóla, visszatöltöd az egész szervert a Windows Server Backup-al készített mentésből.
Ha a Felhasználó véletlenül töröl leveleket, visszahozod a Recovery Folderből.
A backup nélküli megoldás nagyvállalati, több szerveres környezetbe való, részletek a hivatkozott cikkben.
"Ráadásul ha fizikailag gondolom ez is ugyanabba a nagy blob db-ben van, mint a többi adat. Tehát ha ez sérül, akkor a "backup" is sérül, ha a hibás részeket is lereplikálja. "
Nem így működik a replikáció.

Szálnyitó kérdésem fennáll: mihez kell _Neked_ a mailbox szintű visszatöltés?

Üdv,
Marci

- Visszaállítás céljából, ha a user kitöröl valamit
- Visszaállítás céljából, ha nem a user törli, de kitörlődik valami
- Visszaállítás céljából, ha valaki kitörli a user fiókját (feltörik a gépet, vagy akármi)
- Visszaállítás céljából, ha meghal a vas

Nagyjából ennyi.
--
Discover It - Have a lot of fun!

Hello,

Milyen időközönként tervezel menteni és hány példányt őrzöl meg?

Ha olcsón akarod megúszni a dolgot, az alábbiak megfontolását javaslom.

Az első kettőre alkalmas a megfelelő Retention Policy beállítása az itt leírtak szerint: http://technet.microsoft.com/en-us/library/bb123507(v=exchg.141).aspx
Megfelelő szabad lemezterülettel és erre vonatkozó igénnyel akár örök időkre megőrizheted az összes levélváltozatot is - bár gyanítom, hogy a valós felhasználói igény ennél alacsonyabb lesz.
Mindenesetre a hagyományos mentések ilyen környezetben ritkán kerülnek 1 hónapnál hosszabban megőrzésre, a törölt levelek 1 hónapos megőrzése nem tűnik nagy feladványnak a mai lemezméretek mellett.

A harmadikat kétféleképp lehet kezelni:
1) felhasználó törlése: helyreállítod a felhasználót és újracsatlakoztatod a mailboxát
2) feltörik a gépet: visszaállás teljes mentésből, a mailbox szintű helyreállítás nem segít, mert nem tekintheted ismert állapotúnak a környezetet.

A negyedik is visszaállás teljes mentésből.

Így működhetsz mailbox szintű mentés nélkül is.

Üdv,
Marci

Hello!

Kell hogy legyen szerver karbantartási idő is...(offline full mentés egyből teljes szerverre)
Virtualizációban aztán egy postafiók is reprodukálható...nem csak a teljes adatbázis file.
Egyébként lehet tagolni az adatbázis fájlokat is, ami nem biztos hogy rossz szintén, hiszen ezeket ha dismountolod, akkor kisebb fileokat könnyeben le tudsz koppintani hirtelen.(mondjuk részlegenként).

Onlineban pedig parancssorból is kiexportálhatod pst fileba és már is van egy "fapados" mentésed...
Régebbi exchangehez van pár free export program.

Sőt ezekkel még az is megvalósítható hogy a (L)user gépére átrántod vagy másik tárhelyre ami fizikailag is máshol van. Nyilván ezek sem teljes megoldások, marad a szoftver vásárlás.
Aki exchange-t akar, akarjon vásárolni más szoftvereket is.

Szóval azért van pár megoldás, nyilván a helyzet hozza akár ezek kombinációját is.

TomSoft

az egyik valoban alma, a masik meg korte. Az archivalas nem menteni akar, hanem megorizni. A kettonek azert van kozos metszete, kb. mint a -2 .. 10 ill. a 0 .. 15000 halmazoknak. Nem azt mondom, hogy a mentesnek nincs letjogosultsaga (bar arra azert kivancsi vagyok, hogy az megis mire eleg), hanem azt, hogy az finoman szolva karesz, ha csak mented a leveleidet, mert jo par olyan kihivasra nem tud mit mondani, amelyekre egyre egetobbek a vallalkozasok szamara. Magyarorszag sajnos ez ugyben is elegge le van maradva, de van tobb olyan szolgaltato (nem ebben az orszagban), ahol az archivalas szeriatartozek, beepitett szolgaltatas, mert a mentes az emailekkel kapcsolatos problemaknak csak egy szeletere ad valaszt...

Diktatorok kezikonyve

A postafiok mentese peldaul azert jo, mert nekem van tizezer levelem, es egy esetleges recovery utan ezeket nem szeretnem az inboxomban latni. Mert attol meg nem vagyok boldog, hogy ezek a levelek megvannak, nekem pontosan abban a mappaszerkezetbe kell legyenek, amiben voltak, kulonben hasznos idot toltok azzal, hogy ujrarendezzem a mailfiokomat.

Ugyanakkor peldaul en ezeket a postafiokomban szeretnem latni, nem csak valami tavolrol szaglaszhato verzioban, vagyis az szamomra keves, hogy az archivalo szerveren nezegethetem oket.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

igen, ez a 'pontosan abban a mappaszerkezetben' az a -2 .. 0 kozotti dolog, amit nem tud reprodukalni az archivalas. Bar ez sem feltetlen igaz, mert ha a szerveren van pl. egy sieve szabalygyujtemenyed, akkor az archivumbol visszaallitott level is pont abba a mappaba esik be, mint amikor eloszor erkezett. De az valo igaz, hogy ahogyan az imap kliens (ezen felul) ide-oda mozgatja a mappak kozott, azt valoban nem tudja reprodukalni az archivalas.

Btw. mostmar azt is tudod, hogy a levelet barmikor kinyerheted eredeti formajaban az archivumbol :-)

Diktatorok kezikonyve

Ha van sieve szabalygyujtemeny... szerintem a cegek 95%-anal azt sem tudjak, mi az a sieve, tekintve, hogy kizarolag a Dovecot ad ala ertelmes implementaciot, es a cegek legtobbjenek Courier van (mar ahol nem peldaul Exchange, Lotus Notes, vagy epp GroupWise uzemel).

Kenyes tema ez. Kicsit olyan Nap-Hold-Mars-Jupiter egyuttallasos szaga van.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nekünk is kellett egy postafiók szintű mentés. A pst mentést megcsináltuk archívumnak, de kellett egy állandó (ingyenes) megoldás.
Mivel az email gateway úgyis egy Linux volt, így a Linuxon helyben az összes bejövő és kimenő emailről lerakok egy másolat helyben. (Eximmel). Ezen a két nagy közös tárolón fut egy cron script, ami szétválogatja a fájlokat. Bejövő levelek a címzett, kimenőek a feladó email címe alapján, külön mailboxba szétpakolja őket. Egy másik script a mailboxokat egy okos ldap lekérdező script igazgatja, ha változás van az AD-ben. Persze a mailboxok imappal megnézhetőek, ha a cég vezető esetleg utána akar nézni valaki levelezésének. (Tudom, ez megkerülése az AD jogosultságoknak és így non secured meg ISO 9001 compatible, de kit érdekel.) Meg persze az Outlook almappáit se fogja lementeni az usernek, meg a naptárját se. De az emailek megvannak.
--
#conf t
#int world
#no shut

Természetesen tudnak, bár nem hivatalos formából. Aláírva nincs semmi, de mit is kellene? Aki céges emailről levelezik, természetesnek kell hogy vegye, hogy ellenőrizve van. Arról nem is beszélve ugyebár, hogy munkaidő, céges erőforrások, stb. Vagy pl. ha ügyfelet veszít a cég és hirtelen távozik az egyik alkalmazott is. Gyanús esetek, amiket ki kell vizsgálni. Egyébként szvsz céges IT környezetben a privacy fogalma értelmetlen.
Másik dolog. Egyszer régen egy cégnél raktam fel keyloggert és képernyőlopót is userek gépén, annyira para volt a cégtulaj. Na ez azért nekem is sok volt, felfordult a gyomrom, több ilyen melót nem vállaltam.
--
#conf t
#int world
#no shut

duplatenyer.

Természetesen tudnak, bár nem hivatalos formából.

a blikkben olvastak vagy az indexen? LOL

Aláírva nincs semmi, de mit is kellene?

tehat nem jarultak hozza, hogy barki is olvasgassa a leveleiket

Aki céges emailről levelezik, természetesnek kell hogy vegye, hogy ellenőrizve van.

meg egy duplatenyer. Eloszor is mi az, hogy "ellenorizve van"? Femdetektoron kell athaladni? Kamera van a wc-ben? Megmotoznak kifele menet?

Arról nem is beszélve ugyebár, hogy munkaidő, céges erőforrások, stb.

bullshit. Kinaban talan elmegy ez az erveles, meg lehet, hogy par ev mulva orbaniaban is, de az EU-ban nagyon deresre huzzak az ilyen balf*sz cegvezetot, na meg aki csinalta az egeszet (rolad van szo), mert ritka az a cegvezeto, aki elore all, es elviszi a balhet.

Vagy pl. ha ügyfelet veszít a cég és hirtelen távozik az egyik alkalmazott is.

mi koze mindennek egy sunyi, pitianer lehallgatasi ugyhoz?

Gyanús esetek, amiket ki kell vizsgálni.

igy van, mint pl. ezt az esetet is. Mar elore latom lelki szemeimmel, hogy nagyon el lesz intezve a segged...

Egyébként szvsz céges IT környezetben a privacy fogalma értelmetlen.

duplatenyer ismet. Eloszor is, ha a dolgozo altal alairt(!) IT-policyban nincs rogzitve, hogy magan leveleket, pl. hvg napi hirlevel, (worst case) banki ertesitok, stb. nem szabad a ceges cimre kuldetni, akkor ezt a dolgozo lazan megteheti. Ezek viszont jozan esz szerint is leveltitoknak szamitanak, amibe senkinek nem szabad beleturnia, meg akkor sem, ha elveszitett egy ugyfelet a ceg.

Másik dolog. Egyszer régen egy cégnél raktam fel keyloggert és képernyőlopót is userek gépén, annyira para volt a cégtulaj. Na ez azért nekem is sok volt, felfordult a gyomrom, több ilyen melót nem vállaltam.

de ezek szerint megcsinaltad azt is. Ami utan ez az email-gate ugy mar - igazad van - semmiseg. Mutasson valaki egy fejet fogo szmajlit...

Diktatorok kezikonyve

Ha kihúzom ebből a hozzászólásodból a trollszagú szavakat, nem sok minden marad. Arra a pár betűre válaszolok.
Ha van egy munkahelyed, a munkaidőddel a munkaadód rendelkezik. A tevékenységed eredménye az ő tulajdona. A céges emailen végzett forgalmad ellenőrzéséhez éppúgy joga van, mint a munkád ellenőrzéséhez. NEM levéltitok, hanem vállalati erőforrás. Privát levelezésedet irányíthatod céges email címre, de akkor elolvashatják. Informatikai adatbiztonsági oktatásban munkába álláskor mindenkinek részesülnie kéne minden (számítógép használattal járó) munkahelyen, a tűzvédelmi oktatással együtt. Hogy ezt hol és hogyan teszik meg, az annak a dolga, akinek ezt az oktatást el kellene végeznie. Keyloggert sosem telepítettem sem privát életben, sem céges környezetben. Hogy erre miből következtettél, nem világos, de bizonyára szent meggyőződésed a tévedhetetlenségedben elősegített ebben.

--
#conf t
#int world
#no shut

ugy erted, 2 honapig keszultel valami okos(nak latszo) visszavagassal? Eddig tartott, mig a valaki sugott neked, hogy "mondd a kritikajat trollszagunak, es akkor mindenki a te partodra all"? LOL...

Attol, hogy ismet leirod az etikailag (es torvenyileg is) megkerdojelezheto gyakorlatodat, attol az meg ugyanugy bullshit, mint 2 honapja.

Ha van egy munkahelyed, a munkaidőddel a munkaadód rendelkezik.

korrekt, de esetunkre nezve irrelevans

A tevékenységed eredménye az ő tulajdona

ez mar csusztatas, es hamis. Ha munkaidoben irok egy privat emailt a felesegemnek, az az en tulajdonom marad, semmi koze hozza a munkaltatonak, nem is erintheti.

A céges emailen végzett forgalmad ellenőrzéséhez éppúgy joga van,

*HA ELORE* kozli ennek tenyet, *ES* en azt tudomasul vettem az alairasommal. De te magad irtad fentebb, hogy nalatok ilyen hirbol sem volt. Konkluzio: illegalis lehallgatast vegeztel (a keyloggert most hagyjuk is egyelore).

Privát levelezésedet irányíthatod céges email címre, de akkor elolvashatják.

igen, mert TECHNIKAILAG megoldhato. De JOGILAG es ETIKAILAG is sulyos visszaeles.

Keyloggert sosem telepítettem sem privát életben, sem céges környezetben.

hubazz, te tenyleg white hat vagy, LOL... Bar fentebb meg azt irtad, hogy megis megtetted. Dontsd mar el: most hazudtal vagy 2 honapja?

Diktatorok kezikonyve

Barátom, én dolgozok, nem egész nap a hupon trollkodok. :D
Személyeskedésre nem érek rá, ez egy szakmai fórum. Magadra hagylak fröcskölődéseiddel.
Szerk: igazad van, az előző hozzászólásban az utolsó mondatom félreérthető volt. (ha vki direkt félre akarja érteni, pl. te.) Nem telepítettem keyloggert, a lelkiismeretem tiszta és különösen irritál, ha valaki hazugnak nevez. Amennyiben kívánod, a Batyi téren találkozhatunk bármelyik nap délután és személyesen mondhatod a szemembe. Oks?

--
#conf t
#int world
#no shut

Barátom, én dolgozok, nem egész nap a hupon trollkodok. :D

cmd> keylogger.exe, next-next-finish... huhh, de ki is melegedhettel a nagy munkaban...

Nem telepítettem keyloggert, a lelkiismeretem tiszta és különösen irritál, ha valaki hazugnak nevez.

ugy erted, az alabbi mondatod nem egyertelmuen azt jelenti, hogy *te* *felraktal* keyloggert es kepernyolopot?

"Egyszer régen egy cégnél raktam fel keyloggert és képernyőlopót is userek gépén"

LOL, megerhettuk a keylogger + kepernyolopo mutyit is. A szekszardi hazug polgarmester orakat vehetne toled...

Diktatorok kezikonyve

Ezt gondolom átugrottad:

"...ha a dolgozo altal alairt(!) IT-policyban nincs rogzitve, hogy magan leveleket, pl. hvg napi hirlevel, (worst case) banki ertesitok, stb. nem szabad a ceges cimre kuldetni, akkor ezt a dolgozo lazan megteheti."

A levéltitok, ill. magántitok megismeréséhez explicit írásos beleegyezésre van szükség céges környezetben, ergo ha ilyet nem tud felmutatni a cég, akkor jogsértő a levelek turkászása - sőt, a dolgozó távozása után az ilyen levelek tárolása, kezelése is(!)

Megemlítem, hogy az az esetleges tény, miszerint a dolgozó a céges erőforrást magán célra használja még nem jogosít fel téged a levéltitok, illetve a magántitok megsértésére, illetve titkos adatgyűjtésre (keylogger). Az előbbi egyébként céges szabályzat megsértése, az utóbbiak meg btk-s dolgok.

Idéznélek...:

" ( rts | 2013. március 28., csütörtök - 18:11 )

Természetesen tudnak, bár nem hivatalos formából. Aláírva nincs semmi, de mit is kellene? Aki céges emailről levelezik, természetesnek kell hogy vegye, hogy ellenőrizve van. Arról nem is beszélve ugyebár, hogy munkaidő, céges erőforrások, stb. Vagy pl. ha ügyfelet veszít a cég és hirtelen távozik az egyik alkalmazott is. Gyanús esetek, amiket ki kell vizsgálni. Egyébként szvsz céges IT környezetben a privacy fogalma értelmetlen.
Másik dolog. Egyszer régen egy cégnél raktam fel keyloggert és képernyőlopót is userek gépén, annyira para volt a cégtulaj. Na ez azért nekem is sok volt, felfordult a gyomrom, több ilyen melót nem vállaltam."

Nem hiszem, hogy magyarázkodni kellene, de megteszem. Részleteiben úgy nézett ki az ügy, hogy a sambat telepítettem, amire a spywarek az adatokat logolták. A programot a helyi rendszergazda rakta fel a gépekre, mivel a cégvezetőtől utasításba kapta. Ha nem teszi meg, kirúgják. Jól tette. Természetesen a felhasználók is tudtak róla, hiszen elmondta nekik. Persze nem hivatalos formában, erre utaltam.
--
#conf t
#int world
#no shut

A rgazda rosszul tette. Ha írásos utasítást kapott rá, akkor is. A nem hivatalos formában elmondták az annyit jelent, hogy jogilag sem a tájékoztatás, sem a dolgozók beleegyezése nem történt meg, ergo a rendszergizda, meg a cégvezető vélelmezhetően igen-igen komoly btk.-s tényállást valósítottak meg.
És az is jó kérdés, hogy a rendszergizdának volt-e joga arra, hogy pletykáljon erről a dolgozóknak?!

Üldözési mániás, idióta cégvezető, pletykás rendszergazda - a lehető legrosszabb kombináció.

Nem ismerem a keyloggerekre vonatkozó jogi hátteret, de te bizonyára igen. A céges emailek használtára vonatkozókat viszont én is. Csak hogy tisztázzuk. ha személyhez nem köthető email címről beszélünk, a munkáltató a dolgozó beleegyezése nélkül is ellenőrizheti annak tartalmát. Személyhez köthető email cím esetén valóban beleegyezés szükséges, de ez adminisztrációs kérdés.
--
#conf t
#int world
#no shut

Ha jol tudom, tajekoztatasi kotelezettseg viszont minden esetben van. Tehat vagy elore (felvetelkor v. a hozzaferes atadasakor), vagy aktualisan, de tajekoztatni kell a felhasznalokat arrol, hogy a szemelyhez nem kotheto email cimuk ellenorzesre kerul(het).

A keylogger pedig jozan paraszti esszel szemlelve is illegalis.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A szabályozás, amennyire ismerem szigorú. Szerintem igen, minden esetben van tájékoztatási kötelezettség. Az új belépő az aláírásával igazolja ezt, elvileg. Sajnos nyilván aláír bármit, akár megkapta, akár nem.
Van egy olyan kitétel, hogy ha a munkáltató érdekeinek feltételezett sérelme erősebb, mint a munkavállaló személyiségi jogainak tiszteletben tartásához fűződő érdeke, akkor figyelmeztetés nélkül ellenőrizheti a levelezését. Van még valami jogi megkötés az így megszerzett személyes adatok védelmére. De ez már senkit se érdekel, mert akit ki akarnak rúgni, úgyis megtalálják rá az okot.
--
#conf t
#int world
#no shut

mailbox kérdéshez....
A jog szerint -ha jól emlékszem- a dolgozó nevéből képzett elektronikus levelezési címmel rendelkező fiók magánlevelezésnek/magánfióknak minősül. Ezzel ellentétes nyilatkozat tehető, (pl. munkaszerződésben vagy annak mellékleteként) melyet mindkét félnek el kell fogadnia, s célszerű ezt írásban megtenni.
Mondjuk az a faramuci helyzet előáll(t), hogy ma már a „mezei” e-mail is minősülhet írásbeliségnek.

Mosakodni reggel szokás... Egyébként elmehetnél politikusnak, ott szokás ilyen módon kitekerni a saját maguk által állítottakat, ráadásul a keylogger/spyware telepítésben, a rendszer kialakításában való részvétel is olyan, hogy politikusi mértékű takonygerincűség kell hozzá.

Aha, inkább rugassam ki magam. Jó arc vagy. Egyébként mint írtam, több olyan dolgot nem vállalok és ez nem volt egy jó lap a főnökeim felé. Így szerintem nem vagyok takonygerincű. Persze ha szerinted mint főmegmondó szerint az vagyok, akkor biztos úgy is van. Büntess meg, kérlek!
--
#conf t
#int world
#no shut

Most a helyi rendszergazda lett fenyegetve kirúgással, ha nem rakja fel, vagy te? Mivel a keylogger alapban _illegális_ titkos adatgyűjtést végez (ha elkotyogtad "nemhivatalosan" a dolgozók felé, akkor is), így az érintettek nyugodtan feljelentéssel élhettek volna - és akkor bizony... de ezt már írtam.
Neked, vagy a helyi rendszergazdának az lett volna a feladata, hogy a telepítésre vonatkozó utasírást írásban kérje a cég vezetőjétől, tájékoztatva őt a jogi aggályaikról. Ha ezért kirúgás jár, akkor azért a munkahelyért nagyon nem kár. Az írásban megkapott utasítással ugyanis valamennyire védhető a telepítést ténylegesen végző hátsója egy esetleges feljelentést követően.

Kicsit eltértünk az eredeti topictól. :) Sok józan dolog és igazság van aabban, amiket írsz, ezért válaszolok neked. Nem úgy, mint a trollnak. Értelmes emberekkel értelmes vitára viszont nyitott vagyok. Szóval:

- Nem "kotyogtam el" semmit mert nem magamról beszéltem
- Jobban belegondolva nem tudom, hogy "elkotyogás" vagy hivatalos tájékoztatás volt mert pont leszarom. Feltételezem, nem hivatalos úton ment ki, ismerve a cégvezetőt de igazából nem érdekel mert semmi közöm hozzá. Úgy általában, nincs közöm ahhoz, ki mit ír alá és ki mit mond el kinek. Nem tudom, ez a része érthető az álláspontomnak? Te pedig hiányos információk alapján ítélkezel. Megkérdőjelezed, hogy miért nem rúgatom ki magam inkább? Már bocs, de nem akarom. Félistennek vagy egy bírónak gondolod magad, vagy mi. Elnézést.
- Valóban úgy feded le magad, ha mindent írásban kérsz. A cégvezetők között hogy ez lekerült-e papírra, arról nem tudok, de megint csak: semmi közöm hozzá és neked se. Céges ticketing rendszerben volt egy ticket a samba telepítésről ha jól emlékszem...
- kirúgással fenyegetni... Hmm. Aki a magyar valóságban él (te talán nem) az tudja, hogy ha a főnöke utasításait nem hajtja végre, akkor repül.

--
#conf t
#int world
#no shut

Reszben egyetertek, reszben nem.

Mozgasserultkent tulsagosan is tisztaban vagyok a hazai munkaeropiac szomoru helyzetevel, ugyanakkor semmi penzert nem mennek bele egy olyan szituacioba, ahol felmerulhet az en sajat buntetojogi felelossegem is. Vagyis, nem telepitenek keyloggert, spyware-t, nem olvasnek bele masok levelezesebe, etc. Es ennek nem elvi oka van, annal sokkal prozaibb: baromi messze van a birosag, es rohadtul utalnam, ha allandoan oda kellene jarkalnom masok hulyesege miatt. Es meg az ugyved is penzbe kerul. Ha ilyen felmerul, es nem tudom elharitani, inkabb felmondok.

Ha valamiben nem vagyok biztos, inkabb 2x-3x visszakerdezek, egyeztetek, hogy tutira ezt szeretnek-e. Ahol normalis a vezetes, ott megertik, ha elmondod, hogy mik a kockazatok, adott esetben papiroznak, ha ezt kered. Ahol nem ertik meg, ott valoszinuleg nem vedenek be, ha birosagra kerul a dolog, kovetkezeskepp goto elozo pont.

A papirozashoz akkor igenis kozod van, ha olyat csinalsz, amihez buntetojogi felelosseg kotodik, mert ha nincs papir, akkor nincs mivel vedened magad. Ezt baromira nem szabad felvallrol venni, mert a buntetjog rettenetesen burokratikus, a ket szep szemednek nem hisz el senki semmit.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez mind igaz, de az élet nem fekete-fehér. Itt eléggé osszemostál dolgokat. Maradjunk precízek.
Konkrét két példában: nem én vagyok az, aki a keyloggert telepíti. Technikailag lehetővé tettem, hogy működhessen. Azt csak hamis tanúkkal vagy bizonyítékokkal tudnák rám kenni, hogy telepítettem. Úgy persze bármit. és aláírást is lehet hamisítani! Szóval az, hogy valaki minden körülmények között bevédi a seggét... a mesében. De igen, mindent meg kell tenni, hogy minél nagyobb biztonságban legyél. Ez 100%.
A levelezéssel kapcs.ban: nem én vagyok az, aki személyiségi jogot vagy levéltitkot sért. Rendszergazdaként azt teszem, amire utasítanak. Ha az az utasítás, hogy adjam át valaki levelezését vagy tegyem lehetővé, hogy valaki levelezése olvasható legyen, átadom a kért postafiókot, de bele nem olvasok. Nem csak azért, mert jogszabályba ütköző, hanem mert kurvára nem érdekel. Az már nem az én dolgom, hogy ellenőrizzem, hogy a dolgozó hozzájárulását adta-e vagy aláírt-e valamit. Írásban kérjek rá utasítást? Ugyan már. Ki kapott valaha is papíron két példányban aláírt utasítást a főnökétől? Email stb. meg semmit nem ér.
Természetesen lehetne még tovább vinni, hogy igen de hallgatólagosan hozzájárultam...Tudomásom volt róla, nem jelentettem... Fizethetem majd a pénzbírságot. He? Okoskodni lehet, de az írjon ilyen kérdésekben, akinek jogászként van gyakorlati jogi tapasztalata. Hogy mire gondolok: a jogszabályokat én is el tudom olvasni, de nem mindegy a bírósági gyakorlat, a precedensek, az ezernyi kiskapu ismerete.
Még egyszer: minden igaz amit leírtál és ígérem, hogy megjavulok és a jövőben sokkal jobban le fogom magam fedni, ha hasonló helyzetbe kerülök. De egy kis megértést kérek.
Személyes: szar munkahelyre nem megyek dolgozni, csak olyan helyre, ahol jól érzem magam. Viszont egy olyan munkahely számomra értékes és nem hagyom ott csak úgy. (A részletek ismerete nélkül kéretik nem belekötni.)
A trollokat (nem rád gondolok) nem szeretném tovább etetni. Túl sok az off és egyébként is túl lett tárgyalva.
--
#conf t
#int world
#no shut

szerintem arcoskodas helyett inkabb fel kene tenned a kezed, hogy "faultoltam, gyerekek, bocs, legkozelebb sportszeruen jatszom...". Tudom, kellemetlen, mert rosszt fenyt vet az emberre, hogy mit tett a kicsi kezevel, de utana tiszta lappal lehet kezdeni. Persze, ha valaki a sajat ganejaban egyre melyebbre sullyedest preferalja, az mas...

Diktatorok kezikonyve

( hnsz2002 v | 2013. 05. 21., k – 18:51 )

Mivel jobb (és ingyenes) megoldást nem találtam, maradt továbbra is az adatok mentésére a new-mailboxexportrequest... (az ismert hibájával: random mailboxok mentése nem sikerül...)
Csináltam egy cmd és egy ps scriptet, ami a mentést csinálja. Kézzel indítva működik, task schedulerből viszont az alábbi hibát adja, pedig az én userem van beállítva neki, amivel egyébként futtatom. 



         Welcome to the Exchange Management Shell!

Full list of cmdlets: Get-Command
Only Exchange cmdlets: Get-ExCommand
Cmdlets that match a specific string: Help *<string>*
Get general help: Help
Get help for a cmdlet: Help <cmdlet name> or <cmdlet name> -?
Show quick reference guide: QuickRef
Exchange team blog: Get-ExBlog
Show full output for a command: <command> | Format-List

Tip of the day #1:

Did you know that the Identity parameter is a "positional parameter"? That means you can use:

 Get-Mailbox "user" instead of: Get-Mailbox -Identity "user" 

It's a neat usability shortcut!

WARNING: The service  () isn't running. Connecting to remote Powershell 
requires this service to be running.
Failed to connect to an Exchange server in the current site.

Valószínűleg valami környezeti változó vagy ilyesmi hiányozhat neki, de nem tudok rájönni hogy mi... Googleban keresve scripteket a problémára, ugyanez a nyűgjük.

exchange-backup.cmd: 


"c:\Program Files\7-Zip\7z.exe" a \\192.168.200.3\sbs\pst\pst-%DATE%.zip E:\backup\pst\*.pst > pstzipoutput.log
del e:\backup\pst\*.pst
powershell -command "" > psout.log

exchange-backup.ps1: 


. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -server server.lan.local
Get-MailboxExportRequest | Remove-MailboxExportRequest -Confirm:$false
$Export = get-mailbox; $Export|%{$_|New-MailboxExportRequest -FilePath \\server\pst$\$($_.alias).pst}

--
The Community ENTerprise Operating System

No offense, de ha 7 hónap alatt nem sikerült megoldani, javaslom hogy bízzatok meg egy olyan céget/embert aki ért hozzá, és sanszosan megoldja gazdaságosabban... :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

:)
nem offolnék itt vadul, de nyilván szubjektív fogalom a klaszter, meg a magas rendelkezésre állás is...
Van akinek a 95% már jó, van ahol a 99,999 is kevés, ilyen egyszerű.
Mindenesetre egy normális 2 nodeos cluster-rel, ha pánik van nem szarom össze magam ameddig okosan méreteztem, hanem nyugiba csinálok egy failovert (vagy a service, vagy a monitorozás, vagy a stb megcsinálja helyettem..), és nyugodtan kiderítem mi a gond a másik node-al.
A normál helyzetnél ez pont dupla annyira megbízható, és a legtöbb kkv-nak untig elég...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Igazából ez mindig vitatéma, csak a másik kedvenc témámra céloztam ("van két szerverem, hogy csináljak belőle enterprise clustert?"), az is ilyen tákolós. Aggasztó, hogy nem a jó megoldást választják az emberek, hanem összebarkácsolnak valamit és csodálkoznak h. "random mailboxok nem mentődnek", ettől azért rohadtul nem lennék nyugodt.

True, világos, de a semminél mindenképpen több.
Egyszerűen tényleg nem determinisztikus. Lefut a script. Ha másnap megnézem a statust, akkor van 1, ami failed. Lefut következő nap, épp sikerült mind. Lefut megint következő nap, 2 failed, de két tök másik, mint két nappal ezelőtt...

Annyit vettem észre, hogy általában a nagy mailboxok lesznek failedek (7-10GB). A kicsik (80MB, 300MB...) többnyire jók.
--
The Community ENTerprise Operating System