Server 2008R2 dood; Exchange 2010-mailboxen redden

[Ulster Seedling]

Hallo iedereen,

Tot voor kort draaide hier thuis Server 2008 R2 als Domain Controller en bestandsserver op een Mac mini. Met Hyper-V draaide hierbinnen een VM met Exchange Server 2010. Dit was in eerste instantie een soort experiment, maar na vele problemen heb ik besloten dat dit zo niet langer door kan gaan.

Lang verhaal kort: ik ga zo snel mogelijk overstappen naar een anders systeem (combinatie van Windows Home Server 2011 en Mac OS X Lion Server). Hiervoor moet echter wel de e-mail uit Exchange overgezet (gered) worden. Het punt is nu dat ik de hele server niet meer geboot krijgt, waardoor ik ook niet de e-mail kan overzetten.

De Exchange-VM kan ik natuurlijk eenvoudig draaien door Hyper-V op een (andere) pc te installeren en daar de VM's te importeren (tenminste, ik mag hopen dat dat kan?). Het punt is echter dat Exchange een DC nodig heeft om te kunnen functioneren, en deze DC was de enige en wil nu dus niet meer opstarten.

Mijn doel is eenvoudig: de e-mail (en contacten/agenda's) uit Exchange redden. Data staat (semi-compleet) op een aantal schijven, dus dat zit goed. Als ik die mail heb, kan ik veilig het hele Windows-gebeuren wegmikken en opnieuw beginnen. Hoe ik die e-mail kan redden maakt mij dus niet uit, het moet gewoon gebeuren.

Een chronologisch overzicht van de gebeurtenissen:

• Al tijdenlang zijn er problemen en draait alles instabiel. Dit is echter steeds weer te fixen.
• Drie weken geleden, voor mijn vakantie, is Exchange verhuist van de server zelf naar een VM. Alles leek toen te draaien.
• Twee weken geleden, middenin mijn vakantie, bleek de Exchange-VM geen connectie meet de hebben met de AD-server. Ik kreeg dit niet gefixt en na een tijdje verscheen een memory-fout op de fysieke server. Toen is 'ie automatisch uitgegaan.
• Nu thuis probeer ik het ding weer aan te krijgen, maar ik krijg het niet meer voor elkaar.

Wat ik heb geprobeerd om te reanimeren:

• Ik heb eerder gehad dat de server niet wilde booten. Dit heb ik destijds opgelost door de HDD uit de Mac te halen en met een andere Windows-pc een chkdsk te draaien. De chkdsk kon niet lokaal gedraaid worden, omdat zelfs een installatie-dvd kuren vertoonde. Dit is dus waar ik mee begon.
• Na de chkdsk en het terugplaatsen van de HDD volgde na het booten (na het laadbalkje met "Microsoft Corporation") een BSOD met de melding BAD_SYSTEM_CONFIG_INFO.
• Dit zei mij nog niets, dus probeerde ik een chkdsk lokaal te draaien. Dit lukte inmiddels, echter duurde het "CHKDSK is verifying Usn Journal..." heel lang en eindigde de chkdsk met een fout hierna.
• Na wat zoekwerk bleek de BSOD te slaan op geheugenproblemen. Op zich logisch, denkende aan de memory-fout die eerder verscheen.
• Ik heb de Apple Hardware Test (meegeleverde test van Apple om alle hardwareonderdelen te testen) meermaals gedraaid waarbij soms opgemerkt werd dat het geheugen inderdaad problemen veroorzaakte.
• Als wanhoopspoging heb ik de geheugenmodules nog even omgewisseld en opnieuw geplaatst, waarna de Apple Hardware Test geen errors meer aangeeft. De BSOD blijft echter gewoon verschijnen.
• Inmiddels heb ik ook het geheugen vervangen door het oorspronkelijke geheugen van de Mac, maar de BSOD blijft optreden. Vannacht zal ik de uitgebreide Apple Hardware Test draaien, misschien komt daar wat meer uit over het geheugen.

Misschien overbodig, maar nog een omschrijving van de waarnemingen:

• Gewoon opstarten: alles gaat zeer traag. Na een tijd verschijnt de laadbalk met "Microsoft Corporation" eronder. Deze verdwijnt en na vele minuten verschijnt een BSOD met de melding BAD_SYSTEM_CONFIG_INFO. Bij het opnieuw opstarten wordt de opstarthulp (of hoe het beestje ook heet) aangeboden.
• Veilige modus: Windows blijft hangen op het openen van classpnp.sys. Alles blijft gewoon stilstaan en ik kan niets anders dan de stekker lostrekken.

Eerder heb ik ook vergelijkbare problemen gehad, maar nooit zo erg als nu. De moed is me nu simpelweg in de schoenen gezakt en ik ben bang dat ik hier niet meer zelf uit ga komen. Daarom post ik dit hier in de hoop dat iemand misschien nog tips heeft om de zaak toch weer draaiende te krijgen, of misschien een slimme truc kent om de Exchange-data op een andere manier te redden.

---

Zelf heb ik inmiddels begrepen dat het mogelijk is om Exchange-mailboxes te exporteren als PST-bestand zonder dat hiervoor een werkende DC nodig is. Dit zou ideaal zijn! Het enige is dat ik de Exchange-VM dan aan de praat moet krijgen op een andere Hyper-V-server en ik vond dat je hiervoor de oude VM handmatig had moeten exporteren (wat ik niet gedaan heb en ook niet meer kan doen). Ziet iemand misschien een mogelijkheid in deze richting?

---

Ik hoop dat iemand even mee wil denken en mij wil helpen met dit probleem, ik begin zelf behoorlijk moedeloos te worden. Alvast heel erg bedankt!

Groet,
Jonathan

[DiedX]

Voordat je ook maar iets doet: snapshot die machine eerst

[CH4OS]

DiedX schreef op zondag 28 augustus 2011 @ 00:23:
Voordat je ook maar iets doet: snapshot die machine eerst

Alleen de Hyper V machine is dan te snapshotten, de fysieke machine werkt ook niet meer. ;)[quote]jhogervorst schreef op zondag 28 augustus 2011 @ 00:03:
Wat ik heb geprobeerd om te reanimeren:
• Ik heb eerder gehad dat de server niet wilde booten. Dit heb ik destijds opgelost door de HDD uit de Mac te halen en met een andere Windows-pc een chkdsk te draaien.Wait, whut? Je had eerder problemen met de Windows server en haalt daarvoor de schijf uit de Mac en doe je in een Windows machine een chkdsk?

De chkdsk kon niet lokaal gedraaid worden, omdat zelfs een installatie-dvd kuren vertoonde. Dit is dus waar ik mee begon.

Waarom zou chkdsk niet kunnen draaien als een installatie DVD kuren vertoond? Had je vanaf die DVD de chkdsk gedraaid of zo? :?[q]• Na de chkdsk en het terugplaatsen van de HDD volgde na het booten (na het laadbalkje met "Microsoft Corporation") een BSOD met de melding BAD_SYSTEM_CONFIG_INFO.Ik volg je hier niet, het was toch de schijf uit de Mac? :?[q]• Dit zei mij nog niets, dus probeerde ik een chkdsk lokaal te draaien. Dit lukte inmiddels, echter duurde het "CHKDSK is verifying Usn Journal..." heel lang en eindigde de chkdsk met een fout hierna.Welke fout kreeg je toen, heb je die toen opgezocht met bijvoorbeeld Google?[q]
• Na wat zoekwerk bleek de BSOD te slaan op geheugenproblemen. Op zich logisch, denkende aan de memory-fout die eerder verscheen.Heb je kunnen constateren dat het probleem ook daadwerkelijk in het geheugen zit? Want dan is het geheugen vervangen en klaar. Draai dus op die machine een nachtje lang Memtest86+.[q]• Ik heb de Apple Hardware Test (meegeleverde test van Apple om alle hardwareonderdelen te testen) meermaals gedraaid waarbij soms opgemerkt werd dat het geheugen inderdaad problemen veroorzaakte.Het probleem zit toch in een Windows machine? Of is het nu opeens je Mac?[q]• Als wanhoopspoging heb ik de geheugenmodules nog even omgewisseld en opnieuw geplaatst, waarna de Apple Hardware Test geen errors meer aangeeft. De BSOD blijft echter gewoon verschijnen.Probeer ook eens een andere configuratie van de reepjes, bijvoorbeeld apart als het meerderen zijn. Check met Hardware Compatability lists van je moederbord, of het geheugen écht ondersteund wordt.[q]
• Inmiddels heb ik ook het geheugen vervangen door het oorspronkelijke geheugen van de Mac, maar de BSOD blijft optreden. Vannacht zal ik de uitgebreide Apple Hardware Test draaien, misschien komt daar wat meer uit over het geheugen.Als je na het wisselen van het geheugen nog steeds problemen hebt, dan zit het probleem dus níet in het geheugen, daar op testen heeft dan ook geen zin. Ik krijg het idee dat je Windows op een Mac draait. Hoe draai je dat? Doe je dat via bootcamp, of virtualiseer je die binnen Mac OSX? (Overigens is er van Lion geen server versie, die is samengevoegd met de client versie).

[ Voor 88% gewijzigd door CH4OS op 28-08-2011 00:54 ]

[Ulster Seedling]

CptChaos schreef op zondag 28 augustus 2011 @ 00:39:
[...]
Alleen de Hyper V machine is dan te snapshotten, de fysieke machine werkt ook niet meer.

De VM (en alle data) staan op externe USB-schijven die tijdens de reparatie(poging) niet aangesloten zijn. Zodra ik ga klooien met de VM zal ik natuurlijk een kopie van de VHD-bestanden maken.

Verder zal ik zo misschien een kopie van de HDD van de server zelf maken, ik haal 'm er dan uit en sluit 'm even aan op een andere pc hier. Al is de vraag wat ik aan dat systeem heb, maar oké …

---

Verder ben ik nog aan het testen met het geheugen. Het lijkt toch of één van de bankjes niet helemaal lekker is, maar dat is nog niet 100% duidelijk. Mijn angst is nog dat er iets met het geheugenslot op het moederbord is, aangezien de BSOD ook verscheen met het originele geheugen erin.

[CH4OS]

jhogervorst schreef op zondag 28 augustus 2011 @ 00:48:
De VM (en alle data) staan op externe USB-schijven die tijdens de reparatie(poging) niet aangesloten zijn. Zodra ik ga klooien met de VM zal ik natuurlijk een kopie van de VHD-bestanden maken.

Correct me if I'm wrong: volgens mij kan je VHD bestanden mounten aan een driveletter, wellicht dat je dan de database kan exporteren. Maar dan moet je wel weten waar MSSQL zijn databases opslaat of waar Exchange zijn datastore heeft (volgens mij in MSSQL).

Controleer ook even of er niets aan de hand is met de USB-disk, als de Exchange VM veel heeft aan gestaan, kan ik mij voorstellen dat dat een flinke klap uitdeelt op de USB-disk (die blijft dan namelijk ook draaien).

Verder ben ik nog aan het testen met het geheugen. Het lijkt toch of één van de bankjes niet helemaal lekker is, maar dat is nog niet 100% duidelijk. Mijn angst is nog dat er iets met het geheugenslot op het moederbord is, aangezien de BSOD ook verscheen met het originele geheugen erin.

Je hebt fysiek ander geheugen al gebruikt zei je net en de BSOD bleef, dan ligt het dus niet aan het werkgeheugen. Het probleem zit dan eerder in het moederbord dan in de reepjes geheugen.

[ Voor 5% gewijzigd door CH4OS op 28-08-2011 00:53 ]

[wagenveld]

Je beste kans van slagen is een nieuwe (virtuele) DC bouwen met dezelfde naam, domein etc en en een nieuwe Exchange server bouwen. Dan zou je vervolgens in theorie je database daaraan kunnen knopen en de mailboxes kunnen exporteren:
http://technet.microsoft.com/en-us/library/dd876926.aspx
Geen idee of dat gaat werken, normaal gesproken doe je een system state recovery op de DC om je domein eerst terug te krijgen en dan /recoverserver voor Exchange.

[Ulster Seedling]

CptChaos schreef op zondag 28 augustus 2011 @ 00:52:
Correct me if I'm wrong: volgens mij kan je VHD bestanden mounten aan een driveletter, wellicht dat je dan de database kan exporteren. Maar dan moet je wel weten waar MSSQL zijn databases opslaat of waar Exchange zijn datastore heeft (volgens mij in MSSQL).

Mijn plan was om de Exchange-VM te booten en daarna middels de PowerShell alle mailboxes te exporteren (met een New-MailboxExportRequest). Hopelijk werkt dit dus ook zonder DC. Dit heb ik al eerder gedaan (met DC) en dat werkte toen prima.

CptChaos schreef op zondag 28 augustus 2011 @ 00:52:
Controleer ook even of er niets aan de hand is met de USB-disk, als de Exchange VM veel heeft aan gestaan, kan ik mij voorstellen dat dat een flinke klap uitdeelt op de USB-disk (die blijft dan namelijk ook draaien).

Het betreft een RAID1-schijf, ik ga straks even checken maar ik heb er wel vertrouwen in dat dit goed zit.

CptChaos schreef op zondag 28 augustus 2011 @ 00:52:
Je hebt fysiek ander geheugen al gebruikt zei je net en de BSOD bleef, dan ligt het dus niet aan het werkgeheugen. Het probleem zit dan eerder in het moederbord dan in de reepjes geheugen.

Dat klinkt inderdaad logisch. Het volgende trad echter op, wat weer uitsluit dat het aan het moederbord ligt:

• Hardwaretest: error op MEM 1.
• RAM-bankjes omgewisseld (fysiek).
• Hardwaretest: error op MEM 2.

Ik ga nog even beter testen met het oorspronkelijke en andere geheugen, zodat tenminste duidelijk is wat er defect is.

---

wagenveld schreef op zondag 28 augustus 2011 @ 01:00:
Je beste kans van slagen is een nieuwe (virtuele) DC bouwen met dezelfde naam, domein etc en en een nieuwe Exchange server bouwen. Dan zou je vervolgens in theorie je database daaraan kunnen knopen en de mailboxes kunnen exporteren:
http://technet.microsoft.com/en-us/library/dd876926.aspx
Geen idee of dat gaat werken, normaal gesproken doe je een system state recovery op de DC om je domein eerst terug te krijgen en dan /recoverserver voor Exchange.

Is dit per se noodzakelijk? Kan ik niet (zoals hierboven door mij genoemd) via PowerShell de mailboten laten exporteren? Aangezien het hele Windows-gebeuren straks toch verdwijnt, lijkt het mij veel moeite om een nieuwe DC en Exchange-server op te zetten. Mocht het echter noodzakelijk zijn, dan zal het wel moeten …

[ Voor 20% gewijzigd door Ulster Seedling op 28-08-2011 01:04 ]

[wagenveld]

Ik denk niet dat Exchange gaat willen opstarten zonder AD. Verhaaltje om mijn theorie te ondersteunen:
http://www.msexchange.org...hange-database-part1.html

[Ulster Seedling]

wagenveld schreef op zondag 28 augustus 2011 @ 01:06:
Ik denk niet dat Exchange gaat willen opstarten zonder AD. Verhaaltje om mijn theorie te ondersteunen:
http://www.msexchange.org...hange-database-part1.html

Oei, dat zou heel jammer zijn (en weer flink wat uren gaan kosten).

Heeft iemand nog tips om de DC-server (dus de fysieke server) weer aan de praat te krijgen, of klinkt het hopeloos zoals het in de TS staat?

[CH4OS]

wagenveld schreef op zondag 28 augustus 2011 @ 01:06:
Ik denk niet dat Exchange gaat willen opstarten zonder AD. Verhaaltje om mijn theorie te ondersteunen:
http://www.msexchange.org...hange-database-part1.html

Alleen geldt dat (gezien de URL) voor Exchange 2007, de TS heeft Exchange 2010.

[jimmy87]

Voor Exchange 2010 geldt hetzelfde. Deze start ook niet op zonder AD. Ik denk dat je de beste kans hebt door een nieuwe AD met exact dezelfde naam te bouwen, neem ook precies hetzelfde ip.

[ Voor 45% gewijzigd door jimmy87 op 28-08-2011 01:39 ]

[PeeCee]

Wow, dit klinkt bekend. Mijn AD deed ook crash (Xenserver) en toe wilde Exchange 2010 totaal niets meer. Heeft me een dikke week gekost om opnieuw op te zetten. Heb nu Vollledige back-ups van alle virtuele machines en draai om de twee weken volledige systeem back-ups.

Maar mocht je klaar zijn hiermee, is er een andere mogelijkheid. Export Exchange EDB to PST tools. Niet goedkoop maar erg tijdbesparend.

Stom om te roepen maar BACK-UP!

[PeeCee]

jimmy87 schreef op zondag 28 augustus 2011 @ 01:38:
Voor Exchange 2010 geldt hetzelfde. Deze start ook niet op zonder AD. Ik denk dat je de beste kans hebt door een nieuwe AD met exact dezelfde naam te bouwen, neem ook precies hetzelfde ip.

Jip, dit zou ook kunnen werken maar je Exchange server gaat heel moeilijk doen(mij niet gelukt). Plus dat je AD leeg is je hij dus al je mailboxen als disconnected zet. Als je een hard verwijder beleid voert ben je die dus gelijk kwijt.

[jimmy87]

Klopt inderdaad. De beste kans die je hebt is je AD te herbouwen en alles exact hetzelfde te hebben VOOR je exchange opstart. Dus ook al je mailboxen van tevoor aanmaken in je AD ed. dan heb je een kleine kans dat exchange gaat werken.

[Joseph]

Hieruit zie je de logheid van Exchange. Een reden temeer waarom ik dat nooit wil gebruiken.

Wat zijn de specificaties van de server?

Je exchange draaide in een VM? Pak het VHD bestand, en rip daar de database van Exchange uit. Die valt vast wel uit te lezen.

[CH4OS]

Sef24 schreef op zondag 28 augustus 2011 @ 11:38:
Je exchange draaide in een VM? Pak het VHD bestand, en rip daar de database van Exchange uit. Die valt vast wel uit te lezen.

Het mounten van het VHD bestand is in ieder geval heel simpel en kan zelfs met Computer Management:

Bron

[Ulster Seedling]

Dus mijn beste optie is:

• Kopie van VHD met Exchange-data maken;
• Deze kopie mounten;
• Middels een tooltje de EDB converteren naar losse PST's.

Dan ga ik daar zo maar eens aan beginnen. Hopelijk lukt dit en heb ik geen software van honderden/duizenden euro's/dollars nodig, dat is namelijk niet de bedoeling …

[CH4OS]

Mits je de EDB-bestanden vind, denk ik inderdaad dat dat jouw beste optie is, het scheelt je dan namelijk het werk om de AD opnieuw 1:1 from scratch opnieuw op te bouwen.

[ Voor 37% gewijzigd door CH4OS op 28-08-2011 12:38 ]

[Ulster Seedling]

En daar is de volgende tegenslag: omdat ik snapshots van de Exchange-VM heb gemaakt, moet ik nu met de hand in de Hyper-V Manager elke AVHD (snapshot van de VHD) gaan mergen met de voorgaande (A)VHD tot ik één VHD overhoud. Dat betekent dat ik eerst weer Server 2008 R2 op een pc moet installeren, voordat ik toegang heb tot de Hyper-V Manager.

*zucht…*

[alt-92]

Nieuwe 2008R2 DC in de lucht gooien en een verse 2010 Exchange, maar dan met disasterrecovery mode setup.
Daarna de database restoren in die nieuwe install en de mailboxen waar het om gaat reconnecten aan een user?


Ziehier trouwens de reden waarom je geen VM snapshots van een AD/Exchange server wil maken.
Als je gewoon net zoals het 'hoort' netjes een backup procedure had ingericht was er geen enkel probleem geweest om weer snel in de lucht te zijn.

[Ulster Seedling]

alt-92 schreef op zondag 28 augustus 2011 @ 14:40:
Nieuwe 2008R2 DC in de lucht gooien en een verse 2010 Exchange, maar dan met disasterrecovery mode setup.
Daarna de database restoren in die nieuwe install en de mailboxen waar het om gaat reconnecten aan een user?

Zie jij dit als een betere mogelijkheid dan een EDB-naar-PST-tool gebruiken? Jouw mogelijkheid kost namelijk een stuk meer tijd (maar zal ik zeker uitvoeren als het nodig is).

alt-92 schreef op zondag 28 augustus 2011 @ 14:40:
Ziehier trouwens de reden waarom je geen VM snapshots van een AD/Exchange server wil maken.
Als je gewoon net zoals het 'hoort' netjes een backup procedure had ingericht was er geen enkel probleem geweest om weer snel in de lucht te zijn.

Ik had geen idee dat je geen snapshots van productie-VM's mocht maken, dat kom ik nu pas tegen. Het feit dat er geen back-ups zijn is natuurlijk wel iets wat echt stom van mij is, ik wilde pas beginnen met back-ups maken zodra alles goed draaide. Nou ja, laten we het maar zien als een wijze les …

[ Voor 0% gewijzigd door Ulster Seedling op 28-08-2011 14:50 . Reden: Typo ]

[alt-92]

jhogervorst schreef op zondag 28 augustus 2011 @ 14:49:

Ik had geen idee dat je geen snapshots van productie-VM's mocht maken, dat kom ik nu pas tegen.

kom nou, dat kun je zelf toch ook wel bedenken als je beseft wat een snapshot-in-time doet met een database? Ongeacht of dat nou AD is, MSSQL of Exchange.

Zodra je een snapshot maakt (en niet een VSS-aware backup) neem je een risico dat je bijvoorbeeld mails die verwerkt worden via de logs van je ExchangeDB niet meekrijgt.
Een backup laat je ook de logreplay doen zodat je weer volledig in sync bent.
Zelfde voor AD - die snapshot van vorige week betekent dat je USNs out of sequence lopen (niet zo'n probleem als je maar 1 DC hebt, ok) of die wijzigingen aan accounts niet meeneemt.

Tel daarbij op dat een VM Snapshot een differencing disk image is en het verschil tussen een (VSS) backup waar je een nette restore mee kan doen - zelfs bare-metal als het moet - en een snapshot is overduidelijk.

Snapshots zijn geen backup.

[Trommelrem]

CptChaos schreef op zondag 28 augustus 2011 @ 00:52:
[...]
Correct me if I'm wrong: volgens mij kan je VHD bestanden mounten aan een driveletter, wellicht dat je dan de database kan exporteren. Maar dan moet je wel weten waar MSSQL zijn databases opslaat of waar Exchange zijn datastore heeft (volgens mij in MSSQL).

VHD bestanden kun je zelfs openen met 7zip. Dan hoef je niet met diskpart vdisk attach etc. aan de gang. Sinds Exchange 2007 kun je overigens een EDB van een andere server probleemloos mounten zonder de disaster recovery tools.

alt-92 schreef op zondag 28 augustus 2011 @ 15:08:
[...]

Snapshots zijn geen backup.

Ben ik het niet geheel mee eens. Een backup is bedoeld om terug te gaan naar een vorige situatie in geval van een calamiteit. Hardwarebackups zoals tapes zorgen er voor dat je bij hardwarefailures en softwarefailures terug kunt naar die vorige situatie.

Een snapshot zorgt er bij softwarefailures voor dat je terug kunt naar een vorige situatie, maar het terugzetten gaat aanzienlijk sneller dan bij een hardwarebackup. Snapshots bieden echter geen veiligheid voor hardwarefailures en mogen dus nooit als enige backup worden gebruikt. Maar het is wel degelijk een vorm van backup.

[Ulster Seedling]

Ik ben bezig om van de net geïnstalleerde server een DC te maken om Exchange te kunnen draaien. Daarna hoop ik de database (die ik uit de VHD moet vissen) te kunnen mounten.

Mijn vraag is nu: is het verstandig om het nieuwe domein dezelfde naam te geven als het oude domein, of juist niet? Kan dit Exchange niet van streek maken als ik straks de oude database probeer te mounten?

[Remco]

jhogervorst schreef op zondag 28 augustus 2011 @ 15:41:
Ik ben bezig om van de net geïnstalleerde server een DC te maken om Exchange te kunnen draaien. Daarna hoop ik de database (die ik uit de VHD moet vissen) te kunnen mounten.

Mijn vraag is nu: is het verstandig om het nieuwe domein dezelfde naam te geven als het oude domein, of juist niet? Kan dit Exchange niet van streek maken als ik straks de oude database probeer te mounten?

Je had natuurlijk al gezocht bij Microsoft over disaster recovery van Exchange ?
http://technet.microsoft.com/en-us/library/dd876880.aspx

Hier nog wat links:
http://technet.microsoft.com/en-us/library/dd876954.aspx
http://technet.microsoft.com/en-us/library/ee332321.aspx
http://technet.microsoft.com/en-us/library/ee332351.aspx

[ Voor 13% gewijzigd door Remco op 28-08-2011 16:23 ]

[alt-92]

Trommelrem schreef op zondag 28 augustus 2011 @ 15:29:
Ben ik het niet geheel mee eens. [...]

Een snapshot zorgt er bij softwarefailures voor dat je terug kunt naar een vorige situatie, maar het terugzetten gaat aanzienlijk sneller dan bij een hardwarebackup.

Mits je rekening houdt met de beperkingen, en niet toepast op transactional systemen als databases.
Die hebben eigen, betere APIs daarvoor.

[PeeCee]

alt-92 schreef op zondag 28 augustus 2011 @ 14:40:
Nieuwe 2008R2 DC in de lucht gooien en een verse 2010 Exchange, maar dan met disasterrecovery mode setup.
Daarna de database restoren in die nieuwe install en de mailboxen waar het om gaat reconnecten aan een user?


Ziehier trouwens de reden waarom je geen VM snapshots van een AD/Exchange server wil maken.
Als je gewoon net zoals het 'hoort' netjes een backup procedure had ingericht was er geen enkel probleem geweest om weer snel in de lucht te zijn.

Mocht je dit willen doen: zorg er voor dat je organisationname het zelfde is als het oude.
Deze naam is namelijk opgeslagen in je EDB en mount niet wanneer deze naam afwijkt van de nieuwe configuratie. Anders wordt het knutselen met ADSI om je store gemount te krijgen om de nieuwe store te overschrijven.

Door een verkeerde naam te gebruiken heeft mij dit heeeeel veel tijd gekost(Wijze les ondanks back-up's).

[DennusB]

Ik heb dit ook een keer meegemaakt. Heel leuk.
Wat je moet doen zijn de data store files van Exchange backuppen. Een nieuwe AD inrichten die IDENTIEK is aan de vorige, een nieuwe Exchange bak installeren die IDENTIEK is aan de vorige, de datastores mounten en je kan er weer bij.
Ik heb hier toen uren voor aan de lijn gehangen met MS. Onthoud wel, dat als er 1 servernaam/ADnaam, DNS naam of wat dan ook niet overeenkomt met de vorige omgeving Exchange NIET zal starten!

[Trommelrem]

PeeCee schreef op maandag 29 augustus 2011 @ 09:20:
[...]

Mocht je dit willen doen: zorg er voor dat je organisationname het zelfde is als het oude.
Deze naam is namelijk opgeslagen in je EDB en mount niet wanneer deze naam afwijkt van de nieuwe configuratie. Anders wordt het knutselen met ADSI om je store gemount te krijgen om de nieuwe store te overschrijven.

Door een verkeerde naam te gebruiken heeft mij dit heeeeel veel tijd gekost(Wijze les ondanks back-up's).

Sinds Exchange 2007 is dit iets soepeler geworden. Ik ben onlangs ingehuurd voor een disaster recovery. De plaatselijke systeembeheerder was al bezig met een nieuwe omgeving, maar deze week op een aantal punten af van de vorige omgeving (andere domeinnaam en zelfs een andere organisatienaam). Toch is het gelukt om de EDB te mounten. Toch is het verstandig om volgens de richtlijnen te werken en om alles gelijk te houden.

alt-92 schreef op maandag 29 augustus 2011 @ 08:04:
[...]

Mits je rekening houdt met de beperkingen, en niet toepast op transactional systemen als databases.
Die hebben eigen, betere APIs daarvoor.

Precies. Maar in een SOHO of MKB omgeving waar je geen testmachines hebt om bijvoorbeeld updates te testen is een snapshot een ideaal backupmiddel.

[_H_G_]

Trommelrem schreef op maandag 29 augustus 2011 @ 09:33:
Precies. Maar in een SOHO of MKB omgeving waar je geen testmachines hebt om bijvoorbeeld updates te testen is een snapshot een ideaal backupmiddel.

Hmm, heb een tijdje geleden wat tests gedaan, maar sbs2011 gaat finaal op z'n bek. alt-92's eerdere tip van VSS-enabled backup software (of zelf VSS aansturen) werkt een stuk beter dan snapshots.

[Creep]

Dit probleem al vaker tegen gekomen. Meeste kans op een snelle recovery blijf, server precies herbouwen en datastore mounten. Ik gebruik hiervoor meestal een VM zodat ik eventueel met de werkende exchange kan besluiten of ik de nieuwe of oude server exacte hetzelfde inricht of toch zaken anders wil, zoals een andere organisatienaam.

[Trommelrem]

_H_G_ schreef op maandag 29 augustus 2011 @ 09:39:
[...]

Hmm, heb een tijdje geleden wat tests gedaan, maar sbs2011 gaat finaal op z'n bek. alt-92's eerdere tip van VSS-enabled backup software (of zelf VSS aansturen) werkt een stuk beter dan snapshots.

Het is niet dat het ene beter werkt dan het andere. Snapshots zijn bedoeld als aanvulling op gewone backups, je kunt ze dus niet met elkaar vergelijken. Mits goed gebruikt versnelt het de recovery na bijvoorbeeld mislukte updates. Nog altijd geldt: voor het updaten, eerst backuppen.

[ Voor 8% gewijzigd door Trommelrem op 29-08-2011 10:02 ]

[Ulster Seedling]

Oei … De nieuwe omgeving (DC en Exchange) wijkt af van de oude. De Exchange-install draait nog, ik ga het straks gewoon proberen. Als het niks wordt ga ik de zaak opnieuw opbouwden zoveel mogelijk identiek aan de oude omgeving.

[Jazzy]

Dat het afwijkt maakt niet uit, dat was vroeger een vereiste.

[Ulster Seedling]

De DC en Exchange zijn geïnstalleerd en geconfigureerd, zoals gezegd met andere gegevens dan in de oude set-up. Het lukte mij niet de oude EDB te mounten, wat op zich logisch is.

Zoals hier wordt beschreven heb ik een database aangemaakt met dezelfde naam als de oude database. Deze heb ik gemount en gedismount. Daarna heb ik alle bestanden uit de betreffende map weggegooid, met uitzondering van de EDB. Toen heb ik de bestanden van de oude database in die map gezet, met uitzondering van de EDB, en eseutil /r E00 gedraaid waardoor de nieuwe EDB gevuld werd met de data uit de oude logfiles (die overigens allemaal in orde en zonder beschadigingen waren). De resulterende EDB is 8GB groot, wat vrij realistisch is, dus ik vermoed dat de data goed is overgekomen.

Het lukte om deze database te mounten, ik kan de mailboxen echter nergens terugvinden. Op zich wel logisch, maar ik weet niet goed hoe ik ze wél tevoorschijn krijg Iemand een idee?

Edit. Misschien goed om nog te vermelden: de oude EDB (uit de VHD gevist) was zo'n 4GB groot, de nieuwe is dus dubbel zo groot. Verder ging het recoveren (het wegschijven van de logs naar de EDB) verrassend snel: dit duurde enkele seconden.

[ Voor 9% gewijzigd door Ulster Seedling op 29-08-2011 18:03 . Reden: Toevoeging ]

[wagenveld]

Check disconnected mailboxes eens.

[Ulster Seedling]

wagenveld schreef op maandag 29 augustus 2011 @ 18:11:
Check disconnected mailboxes eens.

Nope, niets te vinden. Ik zal straks eens gaan kijken of ik met PowerShell misschien de mailboxen kan vinden.

[punisher007]

Nog even inhakend op snapshots. Snapshots zijn zeker nuttig, maar in het geval van DC, exchange, database, etc. maak dan een snapshot als het systeem uit staat Zeker in een situatie zoals deze waar het geen productiesysteem betreft.

[Ulster Seedling]

Ik heb nog niet gereageerd op de snapshot-discussie hier, misschien handig als ik toch even wat daarover laat horen

In eerste instantie draaide ik Exchange op de server zelf. Na het uitvoeren van enkele updates is Exchange dermate beschadigd geraakt dat ik er niet meer mee kon werken. (Dit ging om de Exchange-bestanden, niet de databases o.i.d.) Daarop besloot ik met Hyper-V een VM voor Exchange te maken, zodat ik (1) weer een werkende Exchange-server zou hebben en (2) voor het installeren van updates een snapshot zou kunnen nemen, zodat problematische updates altijd weer ongedaan konden worden gemaakt. Gezien het een SOHO-omgeving betreft leek dit de enige optie, ik heb geen tientallen servers waarop ik eerst alle updates kan uittesten.

Het is nooit mijn bedoeling geweest dit te gebruiken als vervanger van reguliere back-ups. Zoals ik echter eerder zei, was ik nog bezig met het opbouwen van het hele netwerk en wilde ik pas back-ups gaan instellen zodra alles af was en goed werkte. Helaas ben ik nooit op dit punt aangekomen

[PeeCee]

Trommelrem schreef op maandag 29 augustus 2011 @ 09:33:
Sinds Exchange 2007 is dit iets soepeler geworden. Ik ben onlangs ingehuurd voor een disaster recovery. De plaatselijke systeembeheerder was al bezig met een nieuwe omgeving, maar deze week op een aantal punten af van de vorige omgeving (andere domeinnaam en zelfs een andere organisatienaam). Toch is het gelukt om de EDB te mounten. Toch is het verstandig om volgens de richtlijnen te werken en om alles gelijk te houden.

Is dat zo? Ik gebruik Exchange 2010 op w2k8 R2, maar echt niet soepel te noemen. ADSI is veel gebruikt.

Hoe zou dit makkelijker moeten?

[Ulster Seedling]

Ook PowerShell vindt geen mailboxes in de database (Mailbox Database HS3 zou de oude mailboxes moeten bevatten):

[PS] C:\Windows\system32>Get-MailboxDatabase | Select Server, StorageGroupName, Name, @{Name="Number Of Mailboxes";expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} | Format-Table -AutoSize

Server          StorageGroupName Name                        Number Of Mailboxes
------          ---------------- ----                        -------------------
WIN-VHAP8VK1O6D                  Mailbox Database 0239675993                   2
WIN-VHAP8VK1O6D                  Mailbox Database HS3                          0

[PeeCee]

jhogervorst schreef op maandag 29 augustus 2011 @ 20:26:
Ook PowerShell vindt geen mailboxes in de database (Mailbox Database HS3 zou de oude mailboxes moeten bevatten):

[PS] C:\Windows\system32>Get-MailboxDatabase | Select Server, StorageGroupName, Name, @{Name="Number Of Mailboxes";expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} | Format-Table -AutoSize

Server          StorageGroupName Name                        Number Of Mailboxes
------          ---------------- ----                        -------------------
WIN-VHAP8VK1O6D                  Mailbox Database 0239675993                   2
WIN-VHAP8VK1O6D                  Mailbox Database HS3                          0

Is die op de oude server of nieuwe omgeving?

Wanneer nieuwe omgeving is de eerste store met twee mailboxen logisch, systeem accounts.

De twee is waarschijnlijk niet leeg, check even de disconnected mailboxen, want exchange kan de oude mailboxen niet koppelen aan accounts die niet meer bestaan en dan worden ze disconnected.

Get-MailboxStatistics | Where-Object {$_.DisconnectDate –notlike ‘’} | select Displayname, Database

[Ulster Seedling]

PeeCee schreef op maandag 29 augustus 2011 @ 23:20:
[...]

Is die op de oude server of nieuwe omgeving?

Wanneer nieuwe omgeving is de eerste store met twee mailboxen logisch, systeem accounts.

De twee is waarschijnlijk niet leeg, check even de disconnected mailboxen, want exchange kan de oude mailboxen niet koppelen aan accounts die niet meer bestaan en dan worden ze disconnected.

Get-MailboxStatistics | Where-Object {$_.DisconnectDate –notlike ‘’} | select Displayname, Database

Dit is allemaal op de nieuwe server. De eerste database is inderdaad van de nieuwe server met de twee systeemaccounts erin. De tweede database is mijn gepoogde herstelde database, die dus 8GB groot is maar geen (disconnected) mailboxes bevat. Zowel in de GUI (Exchange Management Console > Recipient Configuration > Disconnected Mailbox) als via de Powershell krijg ik geen mailboxes te zien.

[PS] C:\Windows\system32>Get-MailboxStatistics -Server WIN-VHAP8VK1O6D | select DisplayName,DisconnectDate,Database

DisplayName                             DisconnectDate                          Database
-----------                             --------------                          --------
SystemMailbox{52c78d31-1e70-4b19-b38...                                         Mailbox Database 0239675993
Microsoft Exchange                                                              Mailbox Database 0239675993
SystemMailbox{a4bc5422-1e1b-4e1a-914...                                         Mailbox Database HS3

[ Voor 33% gewijzigd door Ulster Seedling op 29-08-2011 23:52 . Reden: Quote-probleempje ]

[Ulster Seedling]

Ah, eindelijk eens een sprong vooruit Ik heb de oude database weten te mounten als recovery-database en met PowerShell zie ik de accounts staan:

[PS] C:\Windows\system32>Get-MailboxStatistics -Server WIN-VHAP8VK1O6D | select DisplayName,MailboxGuid

DisplayName                                                 MailboxGuid
-----------                                                 -----------
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX                          bbe71543-0d3d-4250-9741-0c643f3e735f
XXXXXXXXXXXXXXXXXXXXXXXXXX                                  4c0577ca-b54d-42e5-9fa5-459ba9fc328d
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX                             a86519d2-a8a1-4dd9-96d9-5422a0c09874
XXXXXXXXXXXXXXXXXXX                                         3c4057ad-f5a7-4355-abbb-767b8ac2e807
XXXXXXXXXXXXXXXX                                            f7c24b79-82e4-4ba4-beaa-8fc6d0aa8621
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX                             ad99eb75-a11f-4db1-99b2-bd3afecc607a
SystemMailbox{753dfc80-5332-4fc7-acec-41a3b7e1ad34}         3dcdd03c-fa95-4e68-9c80-e05bcbe64024
Microsoft Exchange Approval Assistant                       4e42cd91-9e99-41bb-bb9b-e2ddd32da802
XXXXXXXXXXXXXXXXXXXXXXXXXXXX                                c862fcbd-eb61-47f0-b327-e74a2243008a
XXXXXXXXXXXXXXX                                             87345ecc-1587-49bc-bd01-efe64a82b9ce

Nu nog proberen om die mailboxen op de één of andere manier toegankelijk te maken.

---

Voor de geïnteresseerden (of anderen die ooit in de prut komen te zitten) een kort overzicht van hoe ik de database kon mounten.

Zoals eerder genoemd heb ik de EDB en logbestanden van de oude server kunnen bemachtigen. Hierop heb ik eseutil losgelaten om te zorgen dat deze in Clean Shutdown-state terechtkwam. Toen heb ik een nieuwe recovery-database op de server aangemaakt zonder deze te mounten. Ik heb de herstelde EDB op de plek van de recovery-EDB gezet (en de logfiles dus niet meegekopieerd).

De recovery-database kon echter nog niet gemount worden omdat de Organization Name van de nieuwe Exchange-installatie afweek van de oude Exchange-installatie. Dit heb ik weten op te lossen door een LegacyDN in de AD in te stellen volgens deze uitleg. Hierna kon de database gemount worden en werden de mailboxen in PowerShell zichtbaar.

---

Edit. Ik heb het hierboven beschreven trucje nogmaals toegepast, maar nu met een gewone database. De oude database is nu dus gemount als normale database en middels de Clean-MailboxDatabase-cmdlet zijn de mailboxen herkent en op disconnected gezet. Ik maak nu nieuwe AD-users aan en connect de mailboxen daaraan, met geluk werkt alles zo weer!

Edit 2. Ja hoor, het werkt Het lijkt wel alsof er e-mail van twee dagen verdwenen is, maar dat zal zijn gebeurd tussen het moment dat Exchange overleg en ik de e-mail ergens anders liet opslaan. Maar ja, wat zijn twee dagen op een mailbox met jaren aan mail

Ik ben helemaal happy, ik ga de mailboxen zo exporteren naar PST (met de New-MailboxExportRequest-cmdlet). Dan ga ik Lion Server installeren, daar de mailserver instellen en alles overzetten. Iedereen bedankt voor de hulp!

[ Voor 15% gewijzigd door Ulster Seedling op 30-08-2011 16:34 . Reden: Toevoeging voortgang ]

[PeeCee]

Haha, dit is nu precies waar ik ook tegenaan liep. Daarom zij ik ook dat die organisatienaam gelijk moet zijn want anders zou je tegen dit probleem lopen.

Wel apart dat je de oude store kon mounten eerder, dat stond hij niet toe bij mij in eerste instantie.

MAar ben blij dat het is gelukt

[Remco]

Als je gewoon de recovery steps had gevolgd die je al veel eerder waren gegeven, had je gezien dat daarin precies hetzelfde staat vermeld. Had je 2 dagen gescheeld.....

[Ulster Seedling]

Remco schreef op woensdag 31 augustus 2011 @ 01:36:
Als je gewoon de recovery steps had gevolgd die je al veel eerder waren gegeven, had je gezien dat daarin precies hetzelfde staat vermeld. Had je 2 dagen gescheeld.....

Daar heb je inderdaad gelijk in. Het was echter zo dat ik zoveel informatie (fora, Microsoft-KB's, etc.) had, dat simpelweg niet duidelijk was wat de beste methode was. Het is nu dus op trial-and-error gegaan, waarbij elke stap weer veel tijd koste (combinatie van een trage server en grote bestanden waar ik steeds een kopie van maakte). Na twee dagen bleek ik de oplossing te hebben gevonden die dus ook in de eerste link in dit topic aan me gegeven is.

Achteraf natuurlijk stom, maar ik betwijfel of het echt anders had gekund. Nogmaals heel erg bedankt aan iedereen, overigens