Posts Tagged: ‘MMR’

Best Practices für “Managed Mail Replica” – von der Konfirguration bis zur Deaktivierung

28. April 2014 Posted by Katrin Stephan

 

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:

  1. Der Home-Mail Server des Benutzers.
  2. Eine Richtlinie, welche MMR für den Benutzer aktiviert.
  3. 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 Winken


 

Was ist eigentlich “Managed Mail Replica”?

15. April 2014 Posted by Katrin Stephan

 

Mit Hilfe der Managed Mail Replica (MMR) nutzt ihr die Vorteile von serverbasierten Postfächern und Client Repliken zugleich. Sie ermöglichen, dass Nutzer auf dem Client - wie auf Traveler Endgeräten bereits gewohnt - Mails via Push Service empfangen können. Bei einer missgünstigen Konfiguration kann dies aber schnell zum Nachteil führen. In diesem Artikel wird die MMR Technologie erläutert. In einem späteren Artikel wird auf die Konfiguration von MMR im Detail eingegangen.

Der Vorteil von serverbasierten Postfächern ist im Wesentlichen, dass E-Mails direkt bei Ankunft sichtbar sind und nicht erst auf das nächste Replizierungsintervall warten müssen. Einher gehen aber auch die Nachteile der Reaktionsgeschwindigkeit, da die Daten ja stets erst über das Netzwerk bzw. ggf. sogar Internet übertragen werden müssen.

Bei lokalen Repliken hat man hingegen den enormen Performanceschub in der Bedienung. Wechselt man in einen Ordner oder klickt "Neue E-Mail" so reagiert der IBM Notes Client direkt und ohne Verzögerung. Der Nachteil ist allerdings, dass man die regelmäßigen Replizierintervalle abwarten muss. Gerade bei einem Telefonat "Ich schicke dir das mal eben [...] und schon angekommen?" wird sowas immer gerne zur Geduldsprobe. Von Kunden, die lokale Mail Repliken nutzen und parallel zum Notes Client der Traveler eingesetzt wird, hören wir auch immer häufig die Frage, warum die Mail immer schneller auf dem Handy sei als auf dem PC. Replizier-Techniken sind in der Regel leider eher asynchron und Zeit verzögert, im Gegensatz zu Push-Techniken.

 

Abb. 1: Gleichzeitig eingesetzte Replizier- und Push-Technologie sind dem Benutzer schwer vermittelbar.

 

Mit MMR ist man nun in der Lage, beide Vorteile zeitgleich zu nutzen und die Nachteile über Bord zu werfen. Eine MMR unterscheidet sich technisch kaum von einer normalen lokalen Replik. So kann auch jede bereits vorhandene lokale Replik eines Postfachs einfach in eine MMR umgewandelt werden. Einzig eine Eigenschaft der Datenbank zeichnet die Replik als "Verwaltete Replik" aus: erreicht den Nutzer auf dem Server eine neue E-Mail, so wird diese direkt vom Server an die von ihm lokal verwaltete Replik repliziert. Die Verzögerung beträgt nun kein Replikationsintervall mehr, sondern höchstens wenige Sekunden. Eine MMR ermöglicht somit, dass die vom IBM Notes Traveler bekannte Push-Technologie auch im Client Umfeld Einzug hält.

 

Abb. 2: Mittels MMR werden alle Endpunkte via Push-Technologie versorgt.

Da MMR stets nur vom Server in Richtung Client pusht, ergibt sich aber die vom Anwender ggf. gespürte Abweichung seines Postausgangs. Schreibt der Anwender nun lokal eine E-Mail, so wird diese - korrekte Einstellungen vorausgesetzt - direkt an den Server übermittelt und dem Empfänger direkt zugestellt. Dieser Sendeprozess sorgt in diesem Moment aber nicht vollautomatisch dafür, dass auch die Mailreplik des Anwenders auf dem Server mit der neuen E-Mail versorgt wurde, dies geschieht doch erst im nächsten definierten Replizierintervall. In diesem kurzen Zeitfenster sieht der Anwender somit seine gesendete E-Mail z.B. nicht auf seinem mobilen Endgerät oder in iNotes. Um diesem Effekt möglichst stark entgegen zu wirken, kann der Administrator mittels einer Desktop-Richtlinie Repliziereinstellungen verteilen.

Wenn ihr mehr über MMR erfahren möchtet, müsst ihr entweder den nächsten Blog-Eintrag zum Thema MMR-Konfiguration abwarten oder uns gleich persönlich auf das Thema ansprechen - entweder telefonisch (05251 288160) oder per E-Mail info@itwu.de. Unsere Superadmins freuen sich schon auf eure Fragen.