Onderhoud en defragmentatie

Exchange Defragmentatie en Onderhoud

Voorwoord

De laatste tijd is er op werk het vermoeden gerezen, ondermeer bij mezelf, dat we hard toe waren aan het offline defragmenteren van de exchange database, en het offline controleren op fouten. Er werd mij verzocht hier een planning voor op te zetten. Ik ben echter door documentatie heen gaan werken (oorspronkelijk met het doel een realistische gecalculeerde planning te realiseren) en ben tot de conclusie gekomen dat dit niet van toepassing/gewenst/nodig is. Ik zal het nu proberen uit te leggen, zodat iedereen de feitjes (net als ik) weer een keer voor zichzelf kan verfrissen, en we niet meer in de war raken.

De bekeken tools en hun functies:

Ik heb alle tools die offline bij exchange bijgeleverd worden bekeken die met defragmentatie / consistentie controle te maken hebben. Ik som ze hier snel even op met een korte verklaring

MTACHECK

MTACHECK is een tool om je MTA-queue’s te controleren op corruptie. Wanneer je een hangende queue hebt kan je de MTA-service stoppen en deze tool gebruiken om corrupte berichten uit je queue te verwijderen. Deze worden automatisch in bestanden weggeschreven zodat ze niet zomaar verloren gaan.

ESEUTIL

ESEUTIL, ofwel “Extensible Storage Engine (ESE)” Utility , wordt gebruikt om de Information Store en de Directory te defragmenteren, repareren en te controleren op integriteit. Dit gebeurd op het laagste niveau, de “low-level table structure”. Hij controleerd niet op inhoud of logica. Hij kijkt slechts of er verwezen wordt naar niet aanwezige of corrupte data, en verwijdert dan doodleuk die verwijzingen. Een fijne util om je database weer lopend te krijgen, maar niet als je geen data wilde verliezen. Qua integriteit en reparatie mogelijkheden zet je deze dus enkel in wanneer je de backups niet kan gebruiken en verder moet. Dan is het defragmentatie gedeelte van ESEUTIL nog een mogelijkheid. Ik zal op een later punt uitleggen waarom dit geen necessity is binnen de huidige situatie.

EDBUTIL

Deze is vervangen door ESEUTIL en behoeft dus verder geen verhaal.

ISINTEG

ISINTEG, ofwel “Information Store Integrity” Utility is een utility voor 2 zaken.

1. De eerste is zorgen dat de backups goed werken. Dit gebeurt automatisch:
   Each object within Exchange is identified by a Globally Unique Identifier (GUID). The GUID is partially based on time. If you roll back a server, it is theoretically possible to duplicate GUID values for other objects that have since been created in the Organization. Therefore, the GUIDs must be patched during the backup process. This happens automatically through API calls when Exchange is backed-up ONLINE. When it backed-up OFFLINE, you must use this command to patch the GUIDs.

2. Zijn 2e doel is het op logisch niveau repareren en controleren van de database. Bij vreemde problemen als lege mailboxen, mails waarin de headers ineens weg zijn etc. kan je deze tool inzetten om je database te repareren. Dit is INTENSIEF voor je server en duurt lang. Microsoft raad echter stevig aan in plaats van deze utility je backups te gebruiken. De winst van de utility is beperkt, en de mogelijke schade erdoor veroorzaakt en zoiezo de operatie zelf zullen altijd duurder uitvallen dan een backup terugzetten. De server moet offline, en zal lang bezig zijn, met beheerders er bij.

Onderschrift bij ESEUTIL en ISINTEG van MS: IMPORTANT :You should use ISINTEG and ESEUTIL as a last resort only after you’ve tried to restore your system from backup.

Offline defragmentatie, wanneer heeft het zin?

Allereerst zoals ons bekend was, er geschiedt iedere nacht een online defrag in de gedefinieerde “service-hours”. De defrag claimed echter geen vrije ruimte terug. Dit is “by design”. De lege ruimte die ontstaat in de database wordt vastgehouden, en gevult met nieuwe mails of mailboxen wanneer er ruimte nodig is. Deze zal dus telkens marginaal zijn en veel verschuiven. Wanneer je echter een groot aantal boxen verwijderd van een server (of verhuist), zal er een grote hoeveelheid data vrijkomen, die wellicht niet binnen nu en een jaar gevuld zal worden. In dat geval is het dus zinloos deze te “bewaren” voor Exchange. Een offline defrag zal dan je verloren ruimte terug claimen.
Allemaal heel mooi, maar hoe weet ik nu dan hoeveel ruimte er terug te halen is?
De ruimte die de database bewaart voor nieuwe dingen wordt in de terminologie aangeduid als zogeheten “Whitespace”. Wanneer je wil weten hoeveel whitespace er in jouw database zit (oftewel hoeveel er te winnen is met een offline defragmentatie) kijk dan uit naar een EventID in je eventlog met nummer 1221. Dit event komt na iedere nachtelijke online defrag voor in je eventlog en geeft aan hoeveel whitespace er in je database zit.

Offline integritie check, wanneer heeft het zin?

Wanneer een Exchange server teruggehaald wordt uit de backup, kun je bij missende items/mailboxen/public folders een ISINTEG draaien waarbij deze hopenlijk weer teruggenomen worden. Elke mailbox zal geopend worden, headers geevalueerd worden, items herteld worden en nieuwe indexen en inhoud weggeschreven worden. Dit is zeer intensief en neemt veel tijd in beslag. Daarnaast kan het problemen ten gevolge hebben. De tool voegt verder niet veel toe aan de online integrity check die automatisch iedere nacht loopt. In de eventlog kan je zien wat er tijdens de service-hours geconstateerd is aan ellende en gerepareerd.

Wanneer de database nog steeds niet op wil komen kan je ESEUTIL draaien, welke gewoon missende of beschadigde referenties wist . Je verliest dus data, maar dat doe je met het doel de server weer lopend te krijgen.