Im vorherigen Artikel habe ich euch schon die Technologie der Managed Mail Replica (MMR) von IBM Notes und Domino näher gebracht - diesmal geht es ums Detail:
Wie verhalten sich MMRs, was ist bei der Konfiguration wo einzustellen, welche Stolperfallen sollte ich beachten und was mache ich in dem Fall, dass doch etwas schief läuft?
Wie bereits erläutert versetzt euch MMR in die Lage, eure Notes Clients direkt vom Home Server des Benutzers via Push mit neuen E-Mails zu versorgen. Der Client ist somit stets up2date und der Benutzer hat ein deutlich performanteres System. Möchte man die Technologie mit Microsoft Outlook vergleichen, so sind MMRs mächtigere lokale OST-Files.
Bei der Konfiguration von MMR geht es um das Zusammenspiel von drei Komponenten:
-
Der Home-Mail Server des Benutzers.
-
Eine Richtlinie, welche MMR für den Benutzer aktiviert.
-
Der Notes Client des Benutzers, welcher eine lokale verwaltete Replik seines Postfachs erhält.
Abb. 1: Mittels einer Desktop Richtlinie wird die MMR erzeugt und eine Verbindung zwischen IBM Domino Server und IBM Notes Client gewährleistet.
Der Benutzer selbst bekommt von der lokalen Replik, bis auf den Performance Schub, reichlich wenig mit. Einzig im Postfach wird er oben links darauf hingewiesen, dass das Postfach auf dem er gerade arbeitet, lokal liegt. Um alles andere kümmert sich der Client selbst. Während der Benutzer in seinem Postfach auf dem Server arbeitet, wird im Hintergrund die lokale Replik erzeugt. Anschließend wechselt der Client automatisch "on the fly" auf diese lokale Replik und der Benutzer arbeitet weiter.
Abb. 2: Das Postfach zeigt dem Benutzer den Speicherort seiner Datenbank.
Für Administratoren oder neugierige Benutzer gibt es auch noch eine weitere Möglichkeit, zu validieren, dass es sich wirklich um eine lokale Replik handelt. In den Datenbankeigenschaften wird eine MMR als Datenbanktyp "Verwaltete Replik" ausgewiesen. Dadurch werden ebenfalls ein Großteil der Einstellungsmöglichkeiten deaktiviert, da diese ja vom Server übernommen und dort zentral eingestellt werden können.
Abb. 3: In den Datenbankeinstellungen erkennt man, dass es sich um eine aktive verwaltete Replik handelt.
Dabei bringen MMRs noch deutlich mehr als nur einen Performance Schub. Sie reparieren sich selbst. Erkennt der Client ein Problem mit der Datenbank wird der Benutzer automatisch auf die Serverreplik umgeleitet und die lokale Replik neu erstellt. Ob das in der Praxis wirklich funktioniert kann ich nur raten. Ich habe nun seit mehr als einem Jahr eine MMR und habe es jedenfalls noch nicht bemerkt, ob ich zwischendurch mal auf der Serverreplik gearbeitet habe.
Konfiguration von Managed Mail Replica
Soviel zur Arbeit mit einer MMR, nun kommen wir zu den Einstellungen der Server-Richtlinie:
Damit eure Mitarbeiter in den Genuss der MMRs kommen, müsst ihr in der Server-Richtlinie eure Desktop-Einstellungen aufrufen und unter dem Reiter "Mail" die Einstellungen für die Mailfiles und die verwalteten Repliken anpassen. Im Feld "Lokale Maildatei" könnt ihr aus dem Drop-Down Menü am besten den Punkt "Verwaltete Replik erstellen oder lokale Replik in verwaltete Replik konvertieren" auswählen. So wird auch bei Benutzern, welche bereits eine lokale Replik auf ihren Rechner haben, diese lokale Replik in eine verwaltete Replik umgewandelt.
Abb. 4: Desktopeinstellungen für MMR: bereits vorhandene lokale Repliken sollte man umwandeln und für den vollkommenen Performance Schub die lokale Mail.Box aktivieren!
Außerdem gibt es bei den MMR Einstellungen die Option "Selektive Replik", mit der man nur einen Teil der Datenbank lokal replizieren kann und der Rest auf dem Server verbleibt. Um den Wechsel unauffällig im Hintergrund vollziehen zu können, sollten aber stets gesamte Postfächer via MMR repliziert werden. Schlußendlich muss man noch entscheiden für welchen Zeitraum die E-Mails lokal vorgehalten werden sollen. Da bei uns eine serverseitige Archivierungsrichtlinie stets alle E-Mails "älter als 365 Tage" archiviert steht diese Einstellung in Abbildung 4 auf 365 Tagen. Möchte man hingegen sicherstellen, dass die E-Mail ewig lokal vorrätig bleiben, erhöht man den Wert entsprechend. Achtung: Dadurch werden Archivierungskriterien nicht übersprungen! Archivierte E-Mails verschwinden auch immer aus lokalen Postfächern, sobald das nächste mal repliziert wird!
Apropos Replizierung: eine MMR repliziert immer dann, wenn auf dem Server eine neue E-Mail bereit liegt und dies unabhängig von den übrigen Replizierungseinstellungen. Dennoch ist es sinnvoll darauf zu achten, dass man auch gleichzeitig die lokalen Replizierungseinstellungen mit Hilfe der Server-Richtlinie unter "Vorgaben - Replizierung" setzt. Damit sorgt man dem Problem vor, dass im Postfach erstellte E-Mails und Entwürfe nicht nur beim Eintreffen einer neuen E-Mail auf den Server repliziert werden. Der Benutzer merkt so etwas spätestens dann, wenn er auch ein Tablet nutzt und unabhängig vom Arbeitsplatz arbeitet. Ohne festeingestellte Replizierungsintervalle kann es an einem ruhigen Tag sonst mitunter Stunden dauern bis die E-Mail auf den Server repliziert wird.
Überwachung und Deaktivierung von Managed Mail Replica
Nachdem die Richtlinie gespeichert und zugewiesen wurde, beginnt der Server selbstständig mit der Bereitstellung der lokalen Repliken. Über den Fortschritt erhält man in der Administrationsoberfläche oder via Konsolenbefehl leider keine Rückmeldung. Hat man nicht entsprechende Monitoring-Lösungen, wie z.B. das ITWU Simple Client Logging, muss man sich ggf. händisch davon überzeugen, dass die lokalen Postfächer umgestellt wurden. Die Benutzer werden es einem auf jeden Fall danken.
Für den Benutzer ist es via Verknüpfungen nun unmöglich, auf seine auf dem Server gespeicherte Postfach-Datenbank zuzugreifen. Nach wenigen Sekunden wechselt er stehts automatisch auf seine lokale Replik. Sollte es doch einmal nötig sein, so muss der Benutzer die Datenbank über den "Database Open"-Dialog (STRG + O) öffnen. Navigiert er auf diesem Wege zu seinem Postfach auf dem Server, switcht das Mailfile nicht auf die lokale Replik.
Solltet ihr irgendwann MMR wieder deaktivieren wollen, z.B. weil eure Nutzer einen ThinClient erhalten und sowieso nur den IBM Notes Client via Citrix durchgereicht bekommen, so könnt ihr die Richtlinie entsprechend anpassen und die lokale bzw. verwaltete Replik löschen lassen. Bei der Übernahme der Richtlinienangaben löscht der Client dann automatisch die lokale Datenbank und leitet den Nutzer wieder auf die in seiner Arbeitsumgebung definierte Datei um.
Abb. 5: Die MMR-Einstellungen können ebenfalls dafür genutzt werden, um lokale Repliken zu verhindern.
Solltet Ihr Unterstützung bei der Einrichtung oder dem RollOut von MMR haben oder Interesse am ITWU Client Logging haben könnt ihr euch jederzeit gerne bei uns telefonisch melden 05251 288160 oder uns an info@itwu.de eine E-Mail schreiben !
Oder habt ihr MMR vielleicht schon im Einsatz? Dann freuen wir uns darauf, über eure Erfahrungen und Einschätzungen in den Kommentaren zu lesen. Hop hop 
