sbs 2003 - Reparere korrupt exchange database

[petterg]

To brukere som har vært fraværende fra mail denne uka rapporterer at de ikke får nye mailer. Webmail klarer ikke å vise innboks og sent, men klarer andre undermapper av disse. Siste oppdatering av deres outlook var 26/10.

 

Andre brukere som har brukt mail den siste uka har ikke meldt om problemer.

 

Natt til 27/10 var det et strømbrudd (server har ikke ups). Dette kan forklare hvorfor problemer har oppstått. Jeg føler derfor at det vil være lurt å gjennoppbygge databasen på nytt for å være sikker på at det ikke ligger noe andre uoppdagede feil i den.

 

Normalt i en slik situasjon ville man antagelig hentet tilbake hele databasen fra backup før strømbruddet (den ble faktisk fullført 3 minutter før strømmen gikk, i følge loggen), men når det oppdages så sent har jo andre brukere gjort endel endringer på sine mailbokser siden siste "friske" backup.

 

Med de begrensninger som finnes i SBS, hva blir beste måten å få frem en frisk database på?

 

Det som virker som faller meg inn som greieste måten er å exportere alle brukere til pst, slette maildatabasen og importere pst'ene. (Det er vel slik på exchange at hvis man sletter maildatabasefila, vil den opprettes på nytt, med alle brukeres maibokser, tomme?) (For de to brukerene med defekte mailbokser må exporten gjøres i deres buffered mode outlook mens den er offline.

Dette er imidlertid en ganske arbeidskrevende metode.

 

Noen annen måte å sikre seg at databasen blir helt frisk?

[nomore]

Hva med å kjøre en sjekk på databasen?

 

http://www.msexchange.org/articles-tutorials/exchange-server-2003/tools/Exchange-ISINTEG-ESEUTIL.html

[conundrum]

Linken til nomore inneholder den informasjonen du trenger. Kort fortalt må du koble fra databasen (dismount), rullere loggfilene inn i databasen (eseutil /r), reparere databasen (eseutil /p), slette loggfilene og til slutt koble databasen til igjen. Operasjonen kan ta alt fra noen minutter til flere timer, avhengig av størrelsen på databasen.

 

"eseutil" er egentlig et generelt verktøy for reparasjon og sjekk av Microsoft JET-databaser. Hvis databasefeilene har forårsaket skade på Exchange-data eller -datastrukturer i databasen, kan det også være nødvendig å bruke "isinteg"-verktøyet.

 

Vær obs. på at "eseutil" skriver data til en midlertidig database, så du må ha en god del ledig diskplass for å kunne foreta en reparasjon. Du kan angi hvor temp-databasen skal plasseres med /t-parameteret.

 

Husk for all del å ta en full backup før du begynner.

[petterg]

Jeg prøvde meg på esutil i safemode for noen netter siden - uten suksess. Fikk to forskjellige feilmeldinger. Googling av begge ga ikke noe annet svar enn at jeg burde hente tilbake databasen fra backup.

[petterg]

Jeg tror egentlig spørsmålet mitt bunner ut i det siste avsnittet på siden 'nomore' linket til:

 

Whether you should leave a repaired database in production is a matter of philosophical disagreement, with your own tolerance for risk factoring in. If you want to be 100% sure that the database is completely OK after successful repair, rather than just being 99.9% sure, then I suggest moving all mailboxes to another database, and then deleting the repaired database. After deletion, next time you start the database, a new one will be automatically generated, and you can move the mailboxes back. If it's a public folder database, then replicate all folders, delete the database, and replicate them all back to a fresh database.

 

I SBS får man ikke lov å opprette en annen database, og følgelig får man ikke flytta mailboksene noe sted. Jeg trenger en alternativ metode for denne prosessen.

[nomore]

Eksportere til PST?

[petterg]

Ja, det jeg heller mot (ref første post i tråden).

Ville høre om noen hadde forslag til mindre arbeidskrevende metoder.

[petterg]

Det ble nyinstallert server.

Jeg snublet over noen flere korrupte filer og tok det som forvarsel om defekt filsystem / harddisk.

 

Fremgangsmåten ble:

Virtualisere kjørende server til vmware på laptop

Bytte disker i server, reinstallere

Kjøre migrasjon til ny hw i.h.h.t guiden fra MS

Migrere exchange mailbokser fra kjørende vm til nyinstallert server

slå av alle smb share på vm

Oppdatere alias i dns server

Flytte dhcp service

Oppdatere dhcp til å bruke ny serverip som dns-server

flytte alle brukerfiler

opprette smb share på server

Nappe ut strømmen av alle switcher i 10 minutter (tvinger alle klienter til å kjøre dhcp-renew)

Melde vm ut av dns, exchange og domenecontroller

Prise seg lykkelig for at alle klienter er konfigurert til å bruke \\domenenavn fremfor \\servernavn for smb, og dedikerte dns-alias for enhver annen service.

[nomore]

Da regner eg med at det ble 2010 eller 2013 på ny server?

[petterg]

nei. Er ikke 16gb ram i den. (Ettersom sbs 2003 tillater maks 4gb)

(du mente sikkert 2011, siden vi snakker sbs)

Endret 6. november 2013 av petterg

[nomore]

Snakket om Exchange versjonen

 

Kan vel da bare anbefale at dere oppgraderer. Er nå to versjoner mellom den dere har og nyeste fra MS.

[petterg]

Hvorfor det?

Eneste brukermessige fordel med exchange 2010 (sbs 2011) er at man slipper 2GB grensen for mailbokser. Til gjengjeld ble message tracking ekstremt adminuvennlig etter 2008.

Så vil man da spandere 20.000 og endel jobb på ny server for å få en fordel og en ulempe som egentlig ikke har betydning?

[nomore]

Nå er ikke de to tingene der den eneste forskjellen mellom 2003, 2007 og 2010(og ikke minst 2013).

 

Foruten at utviklingen ikke har stått stille(det er ganske mye som er nytt og forbedret etter 2003, også for brukerene), så hadde Exchange 2003 End-of-Life i 2009. Vi snakker da om oppdateringer og support. Og det alene bør stå høyt når det gjelder IT-drift. Dette er altså fire år siden.

[petterg]

Jeg har endel nyere exchangeservere rundt om, og ser virkelig ingen annen grunn til å oppgradere noen av dem til nyere versjon så lenge brukerene ikke vil ha noen praktisk nytte av oppgraderingen. Brukerenes opplevelse av serveren er identisk for exchange 2003 og 2011. Det som betyr noe for dem er outlookversjon, og det er jo helt uavhengig av serverversjon.