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:

optionen festlegen:

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

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

schritt 1: die user-accounts eines post-offices exportieren:

das gewünschte post office auswählen:

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

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

blank passwords ist am praktischsten 🙂

und los 😉

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

die zugriffe von anderen entfernen wir

und los….

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:

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!