Sådan undgår du Exchange-katastrofen
Microsofts mailserver Exchange er blandt danske virksomheders foretrukne. Men selvom noget er udbredt, behøver det ikke være den rene barnemad at sætte op. Og går noget galt, kan det lamme hele virksomheden og gøre it-afdelingen svært upopulær.
Version2.dk har talt med it-konsulenten Henrik Walther, der driver www.exchange-faq.dk, og freelance it-konsulentet Christian Gram fra Datagram.dk. Begge har de mange års erfaring med Microsofts postsystem.
En af de ting, der skiller Exchange ud fra postsystemer som eksempelvis Lotus Domino, er, at alle postkasser som udgangspunkt er lagret centralt i en enkelt datafil bygget på Microsofts database-motor Jet (også kendt som ESE ? Extensible Storage Engine).
Filen kan med tiden blive ganske stor, og så kan den også blive korrupt. Eksempelvis når visse file-level antivirus-produkter på Exchange-serveren begynder at scanne den, hvilket kan ende med, at den ikke kan bringes online og dermed heller ikke længere kan tilgås af brugerne.
Hvis et file-level antivirus-produkt er sat til at scanne transaktions-logfilerne kan disse i værste fald også sættes i karantæne, hvilket ligeledes betyder, at mailboks-storen ikke er online og hele mail-systemet fryser.
»Det er derfor, man skal huske at undtage Exchange-datafilerne og -logfilerne fra at blive scannet af file-level antivirus-programmer,« siger Henrik Walther og tilføjer, at datafilen også kan blive korrupt, hvis den eksempelvis ligger på et Storage Area Network (SAN), der benytter forældede drivere eller firmware.
Backup der kikser Problemet med den korrupte datafil kan vise sig først rigtigt at slå igennem, når filen er havnet i backuppen, Exchange-serveren har lidt et disknedbrud, og filen skal hives tilbage fra backup.
For det første er det slet ikke sikkert, den korrupte fil kan genskabes uden videre, hvilket betyder, at den skal repareres. Og den procedure kan tage rigtig lang tid, især hvis filen er stor. Endeligt er reparetionsprocessen et farligt foretagende.
»Som udgangspunkt skal man passe på med at reparere filen, fordi det kan ødelægge eller slette data. Hvis det er muligt, skal man altid restore den fra seneste backup,« siger Henrik Walther.
Udover at reparationsprocessen kan være decideret skadelig, påpeger han også, at det kan være en møjsommelig affære. Det kan eksempelvis tage adskillige timer at reparere en database fil på 100 gigabyte.
»Tidligere var det sådan, at det tog cirka en time for hver to gigabyte - sådan er det dog ikke længere, fordi hardwaren er blevet hurtigere. Men det kan stadig tage rigtig lang tid,« siger Henrik Walther.
Hold det adskilt
For at sikre sine Exchange-data bedst muligt anbefaler Christian Gram, at selve Exchange-applikationen kører på ét sæt diske, datafilen ligger på et andet, og endeligt at filerne med transaktionsloggen ligger et helt tredje sted.
»Det er altid en god idé at holde de tre adskilt, så det hele ikke går tabt, hvis en del af diskene crasher,« siger han og tilføjer:
»Filen kan hurtigt blive på mange gigabyte, hvor alle mailbokse bliver lagret ned i samme fil, og hvis filen går i stykker, og man ikke kan restore sin backup, så kan man bruge logfilerne, hvis man har dem liggende selvstændigt.«
I forhold til filerne med transaktionsloggen forklarer Christian Gram, at de kan bruges til at gendanne en korrupt datafil med, fordi de indeholder informationer om skrivninger og læsninger til og fra datafilen.
Udsagnet bakkes op af Henrik Walther:
»Altid hold datafilerne og logfilerne adskilte.«
Flere databaser
Endeligt er det muligt at lave flere databaser i Exchange 2007 og i tidligere versioner af Exchange Server. Det betyder i praksis, at i stedet for at lægge samtlige data i en enkelt fil, så kan postkasserne fordeles over flere, mindre filer.
Dermed går alle postkasser i organisationen ikke ned samtidig, hvis en enkelt af filerne bliver korrupt. Og desuden er det hurtigere at reparere og genskabe de mindre filer frem for én stor fil.
»Når der er tale om en ikke-clusteret mailboks-server anbefaler Microsoft, at man holder filerne på under 100 GB, det er best practice,« fortæller Henrik Walther.
Sidst men ikke mindst, så er det bydende nødvendigt at teste backuppen, lyder rådet fra både Christian Gram og Henrik Walther. Det er nemlig den eneste måde, det rent faktisk er muligt at se, om det overhovedet kan lade sig gøre at genskabe mail-data, hvilket langt fra er en selvfølge.
Backuppen kan nemlig umiddelbart se ud som om, den er forløbet planmæssigt, selvom selve datafilen rent faktisk er korrupt. En kedelig overraskelse, som den mail-ansvarlige først opdager, når uheldet af ude.
»Såkaldte Exchange-aware backup-programmer undersøger, når datafilen bliver backet up, om den er korrupt, og så får den it-ansvarlige besked om det, inden det er for sent,« siger Henrik Walther, som nævner, at eksempelvis Windows Server Ntbackup er Exchange-aware, og ifølge ham et ganske fornuftigt produkt at benytte til backup af Exchange.
Kommentarer (25)
"Microsofts mailserver Exchange er blandt danske virksomheders foretrukne. Men selvom noget er udbredt, behøver det ikke være den rene barnemad at sætte op. Og går noget galt, kan det lamme hele virksomheden og gøre it-afdelingen svært upopulær."
Hvis det skal være rigtig nemt, så overvej en anden mail-server.
God bud, kunne være Lotus Domino, transaktionsbackup, applicationsbaseret clustering, frit valg af platform, vildt skalerbar !
Der er endda support for Microsofts LookOut klienter :-)
Kunne tilføje, at selvom Exchange er meget udbredt, er det ikke nødvendigvis et godt produkt !
Kunne V2 ikke lave en artikel der sammenligner mail-servere, der er ikke meget nyt i artikler som denne ?
-
1 -
0
Når Exchange er så sårbar, så forstår jeg virkelig ikke hvorfor Microsoft ikke har bygget reparationsfunktioner ind i systemet. Som tidligere Novell Groupwise administrator, så er det en ting jeg godt nok savner i min hverdag.
Kunne tilføje, at selvom Exchange er meget udbredt, er det ikke nødvendigvis et godt produkt !
Helt enig, men ingen er jo nogensinde blevet fyret for at vælge MS produkter:-(
-
1
-
0
Sådan undgår du Exchange-katastrofen: Bruger en anden mailserver.
Den måde at gemme mails på er jo direkte forrykt. Det samme gør sig i øvrigt gældende for Outlook.
-
1
-
0
Hvad er det egentlig der teknisk set er galt med at gemme store mængder af data i 1 fil?
Hvor mange filer gemmer en oracle database sine data i? 1 fil pr. tabel? 1 fil pr. database?
Og et fil system kan vel teknisk set godt sammenlignes lidt med en database? hvor filerne er tabeller osv. Men de er jo spredt ud over et block device. I en database er tabellerne bare spredt ud over en fil.
Problemet med Exchange må være at database implementationen er dårlig.
-
0
-
0
Det er svært at opdatere store filer, man kan ikke bare skrive noget til eller fjerne noget et sted midt i filen. Man kan læse filen ind i rammen, lave de ændringer der skal laves, og så oveskrive hele filen, hvilket er langt den mest almindelige måde at ændre en fil på. Ellers kan man skrive til enden af filen, hvilket typisk gør det praktisk umuligt at holde nogen som helst form for orden på data i filen.
Til databasebrug vil man typisk skrive en ny fil med ændringer i forhold til den gamle og så foretage en sammenskrivning engang imellem.
-
0
-
0
det er kun svært hvis filen ikke er "tom". Kunne man ikke bruge en sparse fil? hvor man først allokere disk blocks når de skal bruges?
eller bare preallokere det hele.
Prøv iøvrigt at skifte filer ud med disk og se hvad der så står:
"Det er svært at opdatere store diske, man kan ikke bare skrive noget til eller fjerne noget et sted midt i disken. Man kan læse disken ind i rammen, lave de ændringer der skal laves, og så overskrive hele disken, hvilket er langt den mest almindelige måde at ændre en disk på. Ellers kan man skrive til enden af disken, hvilket typisk gør det praktisk umiligt at holde nogen som helst form for orden på data i filen."
Teknisk set kan jeg ikke se hvorfor det ikke skulle kunne lade sig gøre at skrive "midt" i en stor fil, hvis den ellers bare er oprettet som sparse.
-
0
-
0
For nu lige at præcisere, du kan godt skrive midt i en stor fil, men du kan ikke med et normalt filsystem indskyde data midt i filen.
-
0
-
0
hvad nu hvis dele af filen er allokeret tomt? Altså
Du åbner en fil skriver fra 0-64k, så hopper du til adressen 256k og skriver videre til 512k.
Er filens størrelse så 512k, eller 256+64?
Med det rette fil system er der ikke allokeret disk blokke som dækker adresserne fra 64k til 256k.
-
0
-
0
Hvor mange filer gemmer en oracle database sine data i? 1 fil pr. tabel? 1 fil pr. database?
Naah det er lidt smartere lavet end det - trods alt.
En meget meget hurtig oversigt kan ses her :
-
0
-
0
Ja altså teoretisk kan du jo definere filen rigeligt stor og så sprede blokke af data således at der er plads til at udvide de enkelte blokke, men det er ikke noget rigtigt dynamisk system, du kan ikke omgøre den beslutning som du tog da du første gang definerede filen. Og i øvrigt kan jeg ikke se hvorledes det system skulle være bedre end flere mindre filer.
-
0
-
0
Man kunne vel have allokeret filen i den maximale fil størrelse som filsystemet tillader. Og så indsætte data på forskellige adresser i filen.
Men jeg er da også helt enig med dig i at det næppe er bedre end flere mindre filer. Jeg mener bare teknisk set at det kan lade sig gøre, og at problemet med Exchange nok snarrer er en ringe implementation end ideen med at gemme emails i en database.
-
0
-
0
Der er ikke nogen der siger en Exchange server er sårbar, det er ihvertfald ikke tilfældet (kun såfremt administrationen/konfigurationen af den befinder sig i de forkerte hænder).
Der er heller ikke nogen der siger du er bundet til at have alle mailbokse liggende i en database. Med Exchange server 2007 Enterprise edition har du mulighed for at oprette op til 50 databaser.
Og hvem siger Exchange ikke er skalarbar?
Det er også for nemt at sige konkurrende mailservere generelt er bedre. Kom med ordentlige argumenter for hvorfor dette er tilfældet :)
Jeg har mere end 11 års erfaring med Exchange, og kan kun sige den performer kanon (særligt nu hvor den gør brug af 64-bit arkitektur), er hamrende stabil og sidst men ikke mindst sikker (ja såfremt den konfigureres ordentligt).
Og nej jeg er ikke religiøs på dette område.
-
0
-
1
Problemer med exchange:
Mailstores er ufleksible.
Best practice for opsætning af Exchange 2007 kræver minimum 8 servere hvoraf mindst 2 foretrækkes som fysiske servere (alt efter temperament, nogle ville også sige 5).
Flytningen af mailbokse mellem mailstores er ikke uproblematisk.
Jeg er enig i at 2007 gør platformen bedre og mere stabil, men at påstå at 2003 var lige så veludviklet og stabil som Domino og Groupwise ville være fantasteri.
Hvis jeg har forstået det ret har de endda indført mulighed for at lave ægte transaktionslog i 2007 - meeeen jeg er lidt i tvivl om det er rigtigt eftersom jeg kun har hørt det fra en MS Gold Partner som bl.a. lever af Exchange løsninger.
IBM er da heller ikke hoppet på limpinden endnu, de anbefaler fortsat 1 ugentlig fuld backup af Exchange, hvor de ellers normalt kan køre infremental forever med ægte transaktionslogs, med det sagt så er det dog et kærkomment tiltag.
Argumentet for brug af mailstores var mindre brug af diskplads - mao. 1 fil [olehat.pdf] fylder kun 1 gang i den enkelte mailstore selvom "alle" mailbokse i mailstoren har modtaget den.
Omvendt er der en del argumenter imod det.
I alle udgaver indtil 2007 skulle den enkelte mailstore "ned" ifb. med restore - mao. hvis du restorer en mailstore kan ingen af brugerne i den enkelte mailstore komme til sin mailboks/kalender/kontakter etc.
Public folders var definitivt en fejl - det må ses som erkendt af MS i og med at de er ved at udfase det og det ikke kan forventes understøttet i næste udgave af Exchange.
Dernæst nogle problemer med måden den enkelte mailboks er opbygget (om dette stadig er tilfældet i 2007 kan jeg være lidt i tvivl om):
Den enkelte mailboks kan ikke som sådan indekseres (på samme måde som man ville gøre en database søgbag that is).
Du kan ikke kæde kalender, mail og kontakt informationer sammen.
Indhold og præsentation kædes sammen, fremfor indhold for sig og præsentation for sig - Lotus har forstået dette og dermed kan den "samme" mail være i alle dine mapper, idet mapper blot er præsentation af dataene.
Af andre quirks: server og klient opgradering skal principielt gøres samtidig......
Rigtig flot i dagens verden.
Du kan ikke fra Exchange serveren styre hvilke versioner af klienten der må connecte og du er dermed nødt til at styre dette på anden vis eller håbe på at brugerne hører efter.
Jeg har i de sidste 2½ måneds tid måttet lide med en outlook 2003 klient og må erkende at det er en pinsel og vil tillade mig at vove at påstå at flertallet af dem som "foretrækker" outlook gør det fordi de ikke har prøvet noget andet [og nej, det tæller ikke at have prøvet v.1 af groupwise klienten, eller v. 3 af notes klienten for den sags skyld].
-
1
-
0
-Best practice for opsætning af Exchange 2007 kræver minimum 8 servere hvoraf mindst 2 foretrækkes som fysiske servere (alt efter temperament, nogle ville også sige 5).
Det kommer vel en del af på størrelsen af dit setup men du kan vel lige regne 2 domain controlere med for få det til at se endnu dårligere ud.
-Flytningen af mailbokse mellem mailstores er ikke uproblematisk.
Hvorfor ? move-mailbox fungere glimrende dog skal det helst scheduleres mens brugeren ikke er på.
-Hvis jeg har forstået det ret har de endda indført mulighed for at lave ægte transaktionslog i 2007 - meeeen jeg er lidt i tvivl om det er rigtigt eftersom jeg kun har hørt det fra en MS Gold Partner som bl.a. lever af Exchange løsninger.
IBM er da heller ikke hoppet på limpinden endnu, de anbefaler fortsat 1 ugentlig fuld backup af Exchange, hvor de ellers normalt kan køre infremental forever med ægte transaktionslogs, med det sagt så er det dog et kærkomment tiltag.
Hvad er ægte transaktions log ? , det er en database at ikke lave en fuld backup engang imellem er da vanvid.
-Argumentet for brug af mailstores var mindre brug af diskplads - mao. 1 fil [olehat.pdf] fylder kun 1 gang i den enkelte mailstore selvom "alle" mailbokse i mailstoren har modtaget den.
Ja det var nu smart dengang så selv IBM har valgt at kopiere det nu 10 år efter.
-I alle udgaver indtil 2007 skulle den enkelte mailstore "ned" ifb. med restore - mao. hvis du restorer en mailstore kan ingen af brugerne i den enkelte mailstore komme til sin mailboks/kalender/kontakter etc.
Sjovt Recovery Storage Groups har været inde siden 2003 i 2000 skulle du forbi en anden server først.
-Public folders var definitivt en fejl - det må ses som erkendt af MS i og med at de er ved at udfase det og det ikke kan forventes understøttet i næste udgave af Exchange.
Svjv lovede MS 10 års support for public folders og mon ikke de husker admin toolet næste gang , men det kan vi jo se når næste beta er klar
-Den enkelte mailboks kan ikke som sådan indekseres (på samme måde som man ville gøre en database søgbag that is).
det er ikke domino hvor du skal lave en ft pr database
-Du kan ikke kæde kalender, mail og kontakt informationer sammen.
Jeg har endnu aldrig skulle bruge all documents til noget udover at forklare folk de ikke skal slette derinde når de lige vil rydde lidt op
-Af andre quirks: server og klient opgradering skal principielt gøres samtidig......
Rigtig flot i dagens verden.
Ja lige som domino hvor du skal have server opgraderet og templateen for at få ny funktionalitet.
Men ingen tvinger dig til at opgradere klienten så længe du er på en OutlookXP
-Du kan ikke fra Exchange serveren styre hvilke versioner af klienten der må connecte og du er dermed nødt til at styre dette på anden vis eller håbe på at brugerne hører efter.
Sjovt der er ellers en funktion til det samme i Exchange
edit:fjernet citat sjusk i bunden
-
1
-
1
Når man læser debatten her, får man næsten det indtryk, at man kun kan vælge mellem Exchange og Lotus (og lidt Novell).
Der er dog ikke så få endda, der anvender mere stabile systemer end Exchange. Personligt foretrækker jeg Postfix.
Men diskussionen handler måske kun om dem, der er så fjollede at bruge Windows på deres servere?
-
1
-
0
Afhængig af til hvilket formål man har behov for en MTA eller mailserver er nogle mere egnet til opgaven end andre.
Men det kunne være interessant at høre dine argumenter for hvorfor det generelt er decideret fjollet at basere den på en Windows server?
-
1
-
1
Hej Jørgen,
Ganske udemærket pointe - problemet i den sammenhæng er vel at finde cases på f.eks. OpenXchange, Hula, Zimbra mv. - selvom alle, ihvertfald featuremæssigt ser fornuftige ud.
Postfix til mail er fint, men ift. samarbejdsplatform mangler den dog en del - der er både Domino, Exchange og Groupwise altså noget mere feature komplette så at sige. Groupwise og Domino kan iøvrigt køres på meget andet end Windows.
Flemming:
-Argumentet for brug af mailstores var mindre brug af diskplads - mao. 1 fil [olehat.pdf] fylder kun 1 gang i den enkelte mailstore selvom "alle" mailbokse i mailstoren har modtaget den. Ja det var nu smart dengang så selv IBM har valgt at kopiere det nu 10 år efter.
Du må have fået noget galt i halsen - de har bestemt ikke indført mailstores.
Det de har gjort er at gøre det rigtigt nemt for folk at bruge en funktion som altid har eksisteret i notes, nemlig at store dokumenter i fælles databaser, og give disse pr. dokument acl'er og sende links ud istedet.
I Exchange verdenen vil det svare til at du via din mail klient med 1 klik kan uploade et dokument til en sharepoint portal, give de brugere du sender dokumentet til adgang til dokumentet, og generere et direkte link som de kan bruge til at åbne dokumentet via deres mail klient.
Det har i princippet altid kunnet lade sig gøre - nu er det bare meget mere brugervenligt.
det er ikke domino hvor du skal lave en ft pr database
Med chance for at misforstå dig - i Domino/Notes verdenen skal du indikere om den enkelte database skal indekseres, og hvordan den skal indekseres. Det var især brugbart i gamle dage hvor man ikke havde så mange ekstra cpu cycles til rådighed.
Jeg har endnu aldrig skulle bruge all documents til noget udover at forklare folk de ikke skal slette derinde når de lige vil rydde lidt op
Nej det er også meningsløst når man ikke kan seperare attachments og mails fra hinanden i Exchange verdenen.
Derudover kunne man forestille sig en projektleder som har en række projekter og modtager en mail med information til flere af dem - hvordan skal han få den mail ind i flere projektmapper i hans outlook? Det kan han kun hvis han sender flere kopier til sig selv - men da visningen af mails kun er et view i Notes verdenen, er det bare at tilføje et link til de enkelte views og vupti, problem solved. Og nej, det er ikke mig som er i en unik tænkt situation.
Præcis ligesom man kan slette foldere uden at slette alle mails i den i Notes, mens man i Outlook skal være helt sikker før man sletter en folder.
Hvad er ægte transaktions log ? , det er en database at ikke lave en fuld backup engang imellem er da vanvid.
En beskrivelse af transactional log: http://en.wikipedia.org/wiki/Transaction_log
Og nej, det er ikke vanvid hvis du kan merge transactions med din backup via transaction loggen.
-
1
-
0
Du må have fået noget galt i halsen - de har bestemt ikke indført mailstores.
Jeg mente DAOS. dvs kopi af single instance på en lidt smartere måde.
-
0
-
0
Hvad er jeres holdning til Zarafa (http://zarafa.com/)? Har hørt meget hype, men intet fra folk, der faktisk arbejder med mail-serving.
-
0
-
0
Hvad er jeres holdning til Zarafa (http://zarafa.com/)? Har hørt meget hype, men intet fra folk, der faktisk arbejder med mail-serving.
Har ikke benyttet det der findes forskellige alternativer til Exchange der "ligner" exchange , postpath og zimbra er også på markedet dog kræver Zimbra vist en outlook connector.
Men de steder jeg kommer har jeg ikke set nogle af dem
-
0
-
0
Der er dog ikke så få endda, der anvender mere stabile systemer end Exchange. Personligt foretrækker jeg Postfix.
Nu er Postfix AFAIK kun en MTA. Jeg antager at dem der anvender Exchange også bruger den som lidt andet end MTA.
[quote]Men diskussionen handler måske kun om dem, der er så fjollede at bruge Windows på deres servere?/quote]
Tsk tsk...
-
0
-
0
Vi bruger Google Apps på arbejdet. Det giver os rigelig funktionalitet: email, tekstbehandling, regneark, præsentation, kalender, hjemmeside til intranet, IM.
Den eneste hage ved det er det kræver en stabil internetforbindelse. Men der er rørende billigt. :-)
/Michael
-
1
-
0
Nu er Postfix AFAIK kun en MTA.
Korrekt - derfor er Postfix også gerne kun en enkelt komponent i den samlede løsning.
-
0
-
0
Vi har kørt med zarafa i snart et år. Og det fungerer, men er lidt kompliceret at sætte op og vedligeholde, da der ikke er en gui til bruger oprettelse og vedligeholdelse. Men tilgengæld er manuallen ganske fyldestgørende.
-
0
-
0
Tilføj kommentar
