groupwise 6 to exchange 2003 migration

vor mittlerweile etwas längerer zeit habe ich ein groupwise 6 system nach exchange 2003 migriert – hier eine kurze mitschrift (falls ich es nochmal machen müssen sollte will ich nicht wieder bei 0 anfangen 😉 ):

allgemeines / vorbereitungen

zuerst müssen alle datenbanken in allen post offices absolut fehlerfrei sein – das erledigt man mit dem groupwise tool gwcheck. dabei können mehrere durchläufe notwendig sein, bis die fehler behoben sind. bei wirklich hartnäckigen fehlern kann es hilfreich sein, die komplette datenbank lokal zu archivieren, die leere datenbank in einen neuen post office zu verschieben und anschließend das lokale archiv wieder rückzuimportieren.

danach auf das letzte service pack upgraden und nochmals mit gwcheck überprüfen.

bei der migration selbst besteht das problem, dass der migrations-user (man benötigt pro post office einen eigenen) proxy-access (also mit anderen worten einfach zugriff) auf alle datenbanken benötigt. dies kann nur der anwender selbst vergeben; oder man setzt alle passwörter zurück und vergibt sich den zugriff selbst (was den positiven nebeneffekt hat, dass die anwender nicht mehr einsteigen können).
dafür gibt es von novell kein tool – hier muss microsofts „gwbulk“ helfen. die letzte (mir bekannte) version ist die 1.9.46 aus dem jahre 2003 – dieses tool taucht aber in keiner microsoft dokumentation auf, man bekommt es nur direkt bei microsoft (oder man kann google bedienen :mrgreen:)… ohne dieses tool schauts nämlich schlecht aus! (einzige mir bekannte alternative – die zumindest einen teil abdeckt – ist matt weisberg’s “GroupWise Password Reset Utility (GWPR)

mithilfe von gwbulk kann man
– alle passwörter ändern
– proxy access für die mig-user vergeben
– alle anderen proxy access zugriffe entfernen
– alle optionalen nicknames entfernen
– einheitlich das adressen-format auf domain.postoffice.account umstellen

als nächstes brauchen wir einen “migrations-server” – bzw. in späterer folge mehrere (ich hatte sechs), da ansonsten die migration zu lange dauert (man kann auf einem server nicht mehrere datenbanken gleichzeitig übernehmen, und die übernahme selbst ist nicht sehr schnell!!).
auf diesem server muss folgendes installiert werden:
– netware client 4.9 sp2
– microsoft iis
– admin pack
– exchange management pack 2003 sp1
– windows messaging system (für mapi) (das exchange server konto nach der installation löschen)
– groupwise 5.5.1 (wichtig: kein neuerer!!!) (verknüpfung mit parameter “/@u-?” anlegen)

auf einem dann noch gwbulk.

vorbereitungen mit gwbulk

mit einem novell account anmelden, der auf das volume auf dem groupwise liegt vollzugriff hat und anschließend das volume mounten (hier auf g:).

gwbulk starten und das verzeichnis der groupwise-domain angeben:
gwbulk in action

optionen festlegen:
gwbulk in action

pro post office benötigt man einen migrations-account – diesen hier angeben:
gwbulk in action

bei proxy access alles auswählen (achtung: warum auch immer bekommt nach dem lauf jeder proxy access, nicht nur der mig user):
gwbulk in action

schritt 1: die user-accounts eines post-offices exportieren:
gwbulk in action

das gewünschte post office auswählen:
gwbulk in action

Fertig (optional: user die man nicht behandeln möchte einfach aus dem csv löschen).
gwbulk in action

schritt 2: die kennwörter der accounts reseten und weitere nicknames entfernen
gwbulk in action

blank passwords ist am praktischsten 🙂
gwbulk in action

und los 😉
gwbulk in action

schritt 3: so, jetzt wissen wir die kennwörter von allen usern. also steigen wir ein und vergeben den proxy-access:
gwbulk in action

die zugriffe von anderen entfernen wir
gwbulk in action

und los….
gwbulk in action

that’s it. wir haben nun von allen accounts das passwort geändert und uns selbst zugriff gegeben. bis jetzt wars einfach…

migration

da die migration an sich wie gesagt lange dauert, habe ich diese mehrstufig durchgeführt. dazu ist es allerdings notwendig, das komplette groupwise system per backup in einer “migrationslandschaft” nachzubauen.

schritt1: backup von groupwise (und nds) ziehen (am tag x)
schritt2: in eine “migrationslandschaft” restoren und ggf. ip’s usw anpassen
schritt3: gwbulk’en
schritt4: export aller mails (kein kalender) bis zum tag x-30 genau 0 uhr

das inputfile für den migration wizard könnte so aussehen (ich würde immer nur einen user nach dem anderen exportieren):

Mode,GrpWise5
Function,EXTRACT
File,x:\_Migration\username
EMail,TRUE
Schedule,FALSE
Phone,FALSE
Appointments,FALSE
Notes,FALSE
Tasks,FALSE
EMailEnd,JJJJMMDD000000 (also x-30)
GWDomain,g:\grpwise
POName,your-po-name
Accounts,x:\_Migration\username\user.txt

in der user.txt steht einfach nur der name des users, ohne domain und post office

optional können in den *.pri files die foldernamen gewechselt werden – z.b. cabinet auf aktenschrank

schritt5: import dieser daten in das exchange system

importieren auch immer nur einen nach dem anderen:

Mode,File
File,X:\_Migration\username\GrpWise.001\GrpWise.PKL
Mailbox,FALSE
ExchStoreDN,path-to-mailbox-store
Container,your-ou
ImportDestination,SERVER

schritt6: produktives system gwbulk’en (ab jetzt ist das schicksal der user besiegelt…)
schritt7: export aller mails von x-30 0 uhr und eine sekunde, sowie alle kalendereinträge, tasks usw

wieder einen nach dem anderen:

Mode,GrpWise5
Function,EXTRACT
File,x:\_Migration\username
EMail,TRUE
Schedule,TRUE
Phone,TRUE
Appointments,TRUE
Notes,TRUE
Tasks,TRUE
EMailEnd,JJJJMMDD000001 (also x-30 + 1 sekunde)
GWDomain,g:\grpwise
POName,your-po-name
Accounts,x:\_Migration\username\user.txt

in der user.txt steht so wie vorhin einfach nur der name des users, ohne domain und post office

schritt8: import dieser daten in das exchange system

Mode,File
File,X:\_Migration\username\GrpWise.001\GrpWise.PKL
Mailbox,FALSE
ExchStoreDN,path-to-mailbox-store
Container,your-ou
ImportDestination,SERVER

das sieht dann so aus:
 exchange server migration wizard in action

user nach user zu migrieren hat den vorteil, dass man nachdem der exchange server migration wizard gertig ist sofort aktionen setzten kann – wie z.b. den errorlevel abfangen oder ein vernünftiges log zu erzeugen; das ist nämlich gar nich sooo einfach! es wird nämlich nur ins eventlog geschrieben, was die fehlersuche bzw kontrolle nicht sehr einfach gestaltet.

daher dumpt man das eventlog nach den gewünschten daten mit dumpel (und den parametern “-d 2 -m MSExchangeMig -f path -l application”) – schon ganz nett, nur sind somit die neuesten events ganz unten im file.

jetzt kommt tac (aus den textutils for windows) ins spiel – dafür hab ich mir ebenfalls (so wie für die ganze migration, diese lief absolut automatisch) ein kleines batch-file erstellt:

@echo off

if “%1%”==”” goto noinput
if “%2%”==”” goto noinput

set ilog=%1%
set olog=%2%
set logaus=nein

echo mit CMD /V:ON STARTEN!!!!!

if exist %olog%_temp del %olog%_temp

for /F “usebackq tokens=1-11*” %%a in (`X:\_Batch\bin\tac.exe %ilog%`) do (
if not !logaus!==ja echo %%a %%b %%i %%j %%k %%l>>%olog%_temp
if “%%k”==”gestartet.” set logaus=ja
)

X:\_Batch\bin\tac.exe %olog%_temp>>%olog%

del %olog%_temp

goto ende

:noinput
echo param1 inputlog
echo param2 outputlog
goto ende
:ende

bleibt noch folgendes zu sagen: zu glauben, ALLE mails, kalendereinträge usw fehlerfrei migrieren zu können ist reines wunschdenken. es funktioniert nicht schlecht, aber es werden doch nicht alle mails übernommen!

folgendes auch gleich merken:
– kalender attachments werden in einem unterordner unter „posteingang“ als eigene dokumente abgelegt
– kalender und aufgaben müssen manuell importiert werden – bzw. erhält der user beim ersten einstieg eine meldung, ob er importieren will
– einladungen, die noch nicht angenommen wurden, werden nur als normaler text übernommen – d.h. alle einladungen sollten vorab angenommen werden!

und noch eins 🙂 :
der migration wizard macht ansich nichts anderes, als über api calls des clients auf den groupwise server zuzugreifen – somit muss man eines ganz dringend beachten: sind in einem ordner mehr als 5000 mails, so zeigt diese der client nicht mehr an – ergo werden diese auch nicht in die migration miteinbezogen (es gibt auch keinen fehler im log)!!! einzige lösung: mit dem groupwise client einsteigen, und die mails so lange auf neue ordner aufteilen, bis man unter 5000 kommt!

7 thoughts on “groupwise 6 to exchange 2003 migration

  1. Auch ich finde die Beschreibung gut. (Mal sehen, ob sie auch den Praxistest standhält.)
    Ich habe mehrere Probleme,
    1. Die Migration an DIESEM Wochenende.
    2. Diese Woche ist wirklich ALLES schief gelaufen und ich konnt mich nicht richtig vorbereiten.
    3. GWBulk ist scheinbar nicht (mehr) im Netz verfügbar, denn ich kann google bedienen.

    Wenn ich das Programm von dir noch an diesem Wochenende zugemailt bekäme, könnte ich die damit gesparte Zeit sinnvoll in etwas Schlaf investieren und wäre dir natürlich ewig zu Dank verpflichtet.
    Ich wollte die Teilmigration schon in der Nacht von Donnerstag auf Freitag gemacht haben, und jetzt ist kurz vor 3 Uhr Samstagmorgen und ich versuche noch immer GWCheck zu einem ersten fehlerfreien Lauf zu bringen. Wenn das so weitergeht kann ich die Migration erstmal komplett vergessen.
    Ich habe schon 2 Migrationen erfolgreich bewältigt, aber ich fürchte, diese hier wird richtig böse.

    Gruß
    Sascha

  2. Hallo,

    Ich bin mit zufall hier gelandet!
    Ich habe nämlich auch problemen gehabt mit GW6.0 –> exchange 2003 sp2
    um zu setzen!!! Ich brauche GWBULK!!!! Wenn jemand es mir rüber schicken könnte!
    Wäre super!!!

    Ich danke euch im voraus!!!
    Mfg Naures (aus holland)!!!!!

  3. Hi,

    alles nicht schlecht, aber das geht alles ganz einfach, soweit auch bei GW7.0….
    Das einzige was mach noch braucht, ist das Novell API Patch 5 !!!
    Und schon gehts… ist auch seit Ende Okt. 2006 vom MS supported..

    Viel Erfolg
    Thomas

  4. Hallo

    ich hoffe hier schaut noch jemand rein?!

    ich finde das gwbulk tool leider auch nicht im Netz
    und benötige es dringend, da ich nur noch knapp 2 Wochen für mein Projekt habe.
    Es wäre super nett wenn du mir das Tool zumailen könntest.

Comments are closed.