Exchange 2010 migraties met -SuspendWhenReadyToComplete?

[Jazzy]

Voor een cross-forest Exchange 2010 naar 2010 migratie overweeg ik om de mailboxen te moven met de -SuspendWhenReadyToComplete parameter. Dan zou ik de daadwerkelijke migratie in één weekend uit willen voeren door alle moves af te ronden. Het gaat om 1000-4000 mailboxen.

Heeft iemand ervaring hiermee? Ik ben vooral benieuwd naar ervaring met hoeveel moves er per uur afgerond kunnen worden en wat je kunt doen om de performance te optimaliseren. De hoeveelheid data die nog overgepompt moet worden is beperkt, het zal vooral gaan om de laatste 5% van de moves.

Iemand ervaring met deze big-bang coexistence?

[Jazzy]

Iemand?

[ZeRoC00L]

Hoe snel het gaat is afhankelijk van de verbinding tussen de exchange servers.
Het belangrijkste is dat je met 'SuspendWhenReadyToComplete' als het ware alvast een pre-copy doet van de data.
Hoe langer het moment tussen pre-copy en definitieve copy hoe meer 'verschillen' er zijn en hoe langer de feitelijke migratie dus echt duurt.

[Jazzy]

Hoe snel het gaat is afhankelijk van de verbinding tussen de exchange servers.

De meeste tijd bij het resumen zit hem niet in het overpompen van data maar in de laatste 5% van het proces waar o.a. de domain controllers aan beide zijden aangepast worden. Ik geloof niet dat de snelheid van de netwerkverbinding hier de bottleneck is, toch?

Heb je er zelf ervaring mee?

[wagenveld]

Jazzy, ook geen ervaring hier maar misschien kun je wellicht 10 test migraties doen met die switch en dan eens kijken hoe lang het duurt om af te ronden. Interessant dan om te weten of de grootte van de mailbox ook van invloed is. Dan zou je een realistische schatting kunnen doen?

[Jazzy]

Nou ja, Zero heeft natuurlijk wel een punt wat betreft de hoeveelheid data die in de laatste slag meegenomen moet worden, maar ik ben vooral benieuwd naar dat laatste stuk. Mijn testomgevingen zijn allemaal verre van vergelijkbaar met een productieomgevingen, alles draait ofwel virtueel op een overbelaste Proliant ofwel in VMware Workstation op mijn laptop.

Maar als niemand echt praktijkervaring heeft dan moet ik het toch maar eens gaan proberen, je moet toch wat.

[Razwer]

Hoe groot zijn je mailboxen als het transferren minder lang duurt dan de laatste 5%?
Laatste keer dat ik bulk moves uit voerde waren het toch echt de mailboxen moven wat lang duurde.
mailboxen varierend van 1gb tot 30gb met gemiddeld 4gb ofzo.

[wagenveld]

Ik zie wat verdwaalde topics op Technet met dezelfde vraagstelling en met de conclusie dat je maar lekker extra software van Quest moet gaan aanschaffen. Ook fijn. Met een dergelijk groot project pak ik meestal toch eerst een pilot groep (IT wellicht?) en gooi die eerst eens over. Of dat nou 10 of 100 users zijn, je krijgt toch een soort baseline waar je wat op kan baseren.

[Jazzy]

Razwer schreef op donderdag 24 mei 2012 @ 21:37:
Hoe groot zijn je mailboxen als het transferren minder lang duurt dan de laatste 5%?
Laatste keer dat ik bulk moves uit voerde waren het toch echt de mailboxen moven wat lang duurde.
mailboxen varierend van 1gb tot 30gb met gemiddeld 4gb ofzo.

Ik doe het transferen van de data van tevoren met de -SuspendWhenReadyToComplete parameter. Het transferen (wat een werkwoord ) bij de laatste slag is maar 2 of drie dagen aan mail dus gemiddeld (!) misschien een 10 MB per maibox maximaal.

Ik heb die andere vragen ook gezien en vond de antwoorden telerustellend. Ik ben ook wel een beetje verbaasd eigenlijk dat deze manier niet vaker gebruikt wordt tegenwoordig, of dat ik in ieder geval geen praktijkervaring kan vinden.

Verder heb ik ervaring met diverse migratietrajecten van Exchange 5.5-2010, GoupWise, Lotus Notes en allerlei IMAP servers naar allerlei versie van Exchange en Exchange Online. Het is waar dat je met Quest tools meer grip hebt op het switch moment maar ook daar is het wel eens afwachten en bidden terwijl je niet precies weet wat er nu wel of niet gebeurt. Om nog maar te zwijgen van moeizame logging en rapportage. Dus die extra grip die je krijgt is relatief.