Exchange 2003 Benutzer Kalender Informationen löschen

[Cosi 10]

Hallo zusammen,

 

Wir wollen von Exchange 2003 auf Zarafa umstellen. Die Test laufen fast Problemlos.

Wir stellen "weich" um. Das heißt, Benutzer für Benutzer.

Dafür exportieren wir die Exchange Postfächer in pst Files und migrieren die Files mit dem Zarafa Migrationstool

in das neue Zarafa Postfach.

Danach wird das Exchange 2003 Konto gelöscht (. Wir legen aber auf dem Exchange für den gelöschten Benutzer

noch eine externe E-Mail Adresse an. Damit auch die verbliebenen Exchange User den Benutzer noch aus dem Globalen Adressbuch

per Mail erreichen können.

Was wir allerdings nicht wollen ist, das die Exchange 2003 Mitarbeiter noch den "alten" Kalender der schon nach Zarafa migrierten User sehen. Das funktioniert

aber komischerweise. bzw. die alten Termine und Serientermine die in der Zukunft liegen werden angezeigt. Neue Termine, die in Zarafa erstellt wurden, wie nicht anders zu erwarten

natürlich nicht mehr.

Wir migrieren gleichzeitig von einem Exchange 2003, als auch von einem Exchange 2010. Bei den Exchange 2010 Usern haben wir das "Terminproblem" nicht.

Also meine Frage: Wieso sehen die Exchange 2003 User noch die "alten Kalender" der Zarafa User. Irgendwo muss der Exchange 2003 die Daten noch puffern.

Die Grenzwerte stehen übrigens bei "gelöschte Postfächer aufbewahren" =0

"gelöschte Objekte aufbewahren" = 30

 

Vielleicht bringt ihr mir da Licht ins Dunkle.

 

LG

Cosi

[Dukel 454]

1. Wieso von Exchange zu Zarafa?

2. Ist der Exchange 2003 und 2010 in der selben Domäne? Dann würde ich eine Migration von 2003 nach 2010 machen und dann von 2010 zu Zarafa.

[Cosi 10]

zu 1:) War mehr oder weniger eine Frage des Geldes. Ein neuer Exchange mit allen Cals hätte laut Angeboten ca das Doppelte gekostet.

zu 2:) Nein, es handelt sich hier um getrennte Domänen.

[NorbertFe 2.038]

Naja, manchmal sollte man etwas weiter als nur auf die Anschaffungskosten schauen. Aber das merkt ihr auch noch. ;)

[Cosi 10]

Wenn es interessiert, hier eine Lösung.

 

Ihr macht das über OWA

Adresse: https://eureOWAAdresse/public/non_ipm_subtree/

dort gibt es das Verzeichnis "Schedule+ Free Busy

In der entsprechenden OU stehen noch immer die Kalenderinformationen.

Da kann man sie explizit löschen.

bearbeitet 6. November 2015 von Cosi

[magheinz 110]

Naja, manchmal sollte man etwas weiter als nur auf die Anschaffungskosten schauen. Aber das merkt ihr auch noch. ;)

Ehrlich gesagt lief zarafa deutlich stabiler, ist einfacher und angenehmer zu händeln und dazu noch günstiger. Das hat sie Evaluierung bei uns ergeben. Dann haben die Großkopferten sich trotzdem für exchange entschieden: weils alle machen...

[NorbertFe 2.038]

Naja ich kann nicht über Instabilität klagen. Und über die Zarafa Installationen die ich gesehen habe könnte ich das gleiche wie du zu Exchange sagen. ;) liegt ja vielleicht auch am eigenen Blickwinkel, oder?

[magheinz 110]

Es liegt immer mit am Blickwinkel. Ursprünglich komme ich aus der linuxwelt.

Das bei unserem Exchange (2*CAS+3*DAG)ab und an ein Dienst einfach nicht läuft, vor allem nach updates ist schon Standard. Der Zugriff aufs Speicherbackend unter zarafa mit Hilfe von mysql ist so simpel, da könnte sich MS eine Scheibe von abschneiden.Bei zarafa fehlt halt ein vernünftiger Client.

 

Beide Systeme haben so ihre Vor- und Nachteile. Hat man eh schon AD, Windowsserver etc sollte man über Exchange nachdenken. Wir kamen ursprünglich aus einer MS-freien Serverumgebung (Novell+Linux) und haben deswegen auch Exchangealternativen angeschaut.Mitlerwiele haben wir AD, Exchange bekommen demnächst MSSQL etc.

Fest steht: Der Arbeitsaufwand die MS-Systeme aktuell und am Spielen zu halten ist höher als der bei unseren Linuxserver(fast nur Debian)

Ach ja: von wie vielen Daten(Postfächer und Gigabyte) reden wir denn hier?

Wir haben 300 Groupwiseuser (ca 500GB Daten) in knapp 2 Wochen umgestellt. Kannst du nicht solange einfach damit leben?

[NorbertFe 2.038]

Naja abgesetzter CAS ist schon lange nicht mehr "empfohlenes" Design. Aber naja. ;) Und Arbeitsaufwand kann ich immer nur einschätzen, wenn ich total veraltete Linux-Systeme "sehe" und höre, die wurden das letzte Mal vor x-Monaten gepatcht, weils ja gar nicht notwendig ist. ;) Aber so hat halt jeder seine Vorstellungen.

 

Bye

Norbert

[magheinz 110]

Naja abgesetzter CAS ist schon lange nicht mehr "empfohlenes" Design. Aber naja. ;) Und Arbeitsaufwand kann ich immer nur einschätzen, wenn ich total veraltete Linux-Systeme "sehe" und höre, die wurden das letzte Mal vor x-Monaten gepatcht, weils ja gar nicht notwendig ist. ;) Aber so hat halt jeder seine Vorstellungen.

 

Bye

Norbert

Für 2010 war das so noch von alle unseren Dienstleistern emfpohlen. Mag sein dass das für neuere Versionen nicht mehr gilt.

Debiansysteme lassen sich sowas von einfach up2date halten, wer das schleifen lässt hat es dann nicht anders verdient. Innerhalb einer Debianversion verändern sich z.B. niemals APIs, Konfigsyntax etc. Das passiert bei Microsoft mit jedem Servicepack.

 

Übrigens: ungepatchte Windowssysteme kenne ich mehr als ungepatchte Linuxsysteme. Das ganze hat nix mit Vorstellungen zu tun sondern mit praktischer Erfahrung.

 

Bleibt die Frage für diesen Fall hier: Von welcher Datenmenge und welchem Migrationszeitraum reden wir hier?

[NorbertFe 2.038]

Das galt auch schon für 2010 nur "eingeschränkt", nur wollten es da noch nicht alle wahrhaben. ;) Ja auch ich hab schon NLB implementiert. ;)

Ich kenne mehr gepatchte Windows Systeme als gepatchte Linuxsysteme. ;) Könnte daran liegen, dass ich damit mehr zu tun habe?

Meinst du mich mit der Datenmenge? Nö, oder?

 

Bye

Norbert

[magheinz 110]

Das mit der Anzahl der gepatchten System ist dann wohl wieder der Blickwinkel ;)

Das es schon für 2010 so war wusste ich nicht. Da bin ich zu sehr Linuxmensch: one tool one job, one server one service. VOr den CAS server in der DMZ stehen dann noch ein Loadbalancer-HApärchen.

Ausserdem, was hätte ich mti den zwei übrigen Standard-Exchangelizenzen machen sollen wenn nicht CAS? :D

 

Mit der Datenmenge meine ich den OP.

Mir stellt sich die -frage ob es überhaupt lohnt das Problem anzugehen oder ob man nicht einfach die Migration schnellstmöglich durchzieht.

[NorbertFe 2.038]

Ausserdem, was hätte ich mti den zwei übrigen Standard-Exchangelizenzen machen sollen wenn nicht CAS? :D

Edge. Hätte mehr Sinn ergeben als NLB hinter einem HA Loadbalancer in der DMZ. ;)

 

 

Mir stellt sich die -frage ob es überhaupt lohnt das Problem anzugehen oder ob man nicht einfach die Migration schnellstmöglich durchzieht.

Normalerweise sollte das ja eher die Wahl sein, es möglichst schnell durchzuziehen. ;)

 

Bye

Norbert

[Cosi 10]

Naja, es sind so um die 1000 Konten und ungefähr 2,0TB Daten. Da es sich hier auch für uns um ein neues Produkt handelt, bevorzugen  wir eine weiche Migration.

Mit einzelnen nicht funktionierenden Postfächern könnten wir besser leben, als wenn überhaupt keine funktionieren.

[magheinz 110]

Edge. Hätte mehr Sinn ergeben als NLB hinter einem HA Loadbalancer in der DMZ. ;)

Wozu einen Edge? Dank anderer Server(owncloud, webserver, mailserver+Mailscannercluster etc) haben wir eh einen openldap als Proxy in der DMZ und haproxy ist ein einfacher, schlanker und gut funktionierender reverseproxy. Das ganze noch doppelt + LinuxHA(pacemaker, corosync etc) und fertig ist die Laube.

Die loadbalancer hängen eh vor der webserverfarm. Zusätzlich machen die noch reverseproxy für das RDS-Gateway.

 

Normalerweise sollte das ja eher die Wahl sein, es möglichst schnell durchzuziehen. ;)

normalerweise...

 

Naja, es sind so um die 1000 Konten und ungefähr 2,0TB Daten. Da es sich hier auch für uns um ein neues Produkt handelt, bevorzugen  wir eine weiche Migration.

Mit einzelnen nicht funktionierenden Postfächern könnten wir besser leben, als wenn überhaupt keine funktionieren.

Ok, das ist ne Hausnummer die man nicht so eben an zwei Wochenenden schafft.

bearbeitet 11. November 2015 von magheinz