none
[Exchange 2010] Public Folder Database in DAG Umgebung erstellen RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Servus Community,

    wir möchten in unserer Zwei Knoten DAG Umgebung eine Public Folder Database mit einem Public Kalender zur Verfügung stellen und stolpern hier so von Fragen zu Problemen. Wir haben die Anzahl der Datenbanken auf unseren Exchange 2010 Standard Servern auf vier reduziert, können aber keine Public Folder Database in der Art und Weise erstellen, wie wir das von normalen Datenbanken kennen.

    Was wir gelesen haben, ist das wir auf jedem Server eine eigene Public Folder Database erstellen müssen (zB: pdb1 und pdb2), dann die Verzeichnishierarchie anlegen müssen und dann die Synchronisation aktivieren. Uns erscheint die Reihenfolge etwas verwirrend. Warum nicht erst die Synchronisation einschalten und dann die Ordnerstruktur anlegen?

    Daraus ergeben sich folgende Fragen:

    • Komme ich mit dem Konzept der einzelnen Public Folder Databases auf jedem Server irgendwie in Konflikt mit dem 5 DB Limit der Standard Version von Exchange? Note: Es existieren bereits vier Postfach Datenbanken.
    • Muss ich tatsächlich erst die Ordnerstruktur auf beiden Servern erstellen, bevor ich die Synchronisation einschalten kann?
    • Wie aktiviere ich die Synchronisation?
    • Wie wird das ganze dann gesichert? Note: Wir sichern derzeit nur den Knoten mit den inaktiven Datenbankkopien. Gesichert werden die Server (virtuelle VMWare Server) mit Veeam Backup & Replication.
    • Gäbe es jetzt etwas zu beachten, hinsichtlich der bald anstehenden Migration auf Exchange Server 2016? Note: Wir gehen davon aus, dass sich die Migration ebenfalls mit einem Swing-By Manöver und einer vorübergehenden Koexistenz zweier Exchange 2010 und zweier Exchange 2016 durchführen lässt, wie es schon bei der Migration von Exchange 2003 auf Exchange 2010 gewesen ist.
    • Weiß hier zufällig jemand, wie sich die öffentlichen Ordner mit öffentlichen Kalendern auf Apple Mac OS Clients mit Apple Mail.app verhält?

    Thx & Bye Tom

    Dienstag, 13. August 2019 14:37
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ad 1. nein, es sind dann auf jedem Server 4 Kopien von Postfach-DB (aktiv oder passiv) plus eine PF-DB gehostet.

    ad 2. ja, die Replikation findet in der alten Public Folder-Architektur pro Ordner statt, daher muss der Ordner natürlich da sein, bevor man die Replikation aktivieren kann ;-) Dafür sind aber alle Replikate lesbar und schreibbar. Hat in Umgebungen mit schlechtem WAN gewisse Vorteile gegenüber der neuen Methodik ;-)

    ad 3. indem Du einem Ordner Replikate in weiteren DBs hinzufügst.

    ad 4. Wenn Du in jeder PF-DB ein Replikat von jedem PF (PF hier = "Public Folder", nicht "Postfach") hast, brauchst Du ja auch nur eine zu sichern ;-)

    ad 5. Migration auf 2016 --> ich würde zuerst migrieren, dann stellen sich all die Fragen nicht mehr. Und die PF-Migration von alt auf neu ist nichts für schwache Nerven.

    ad 6. Mist, gestern hätte ich einfach mal rasch nachschauen können.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 13. August 2019 17:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    es ist schon länger her, aber ich meine mich zu erinnern, dass die Replikationstopologie sich nicht vererbt. 

    Das Video ist zwar für Exchange 2003, aber ja, genau so machst Du das auch in 2010.

    Kalender exportieren/importieren ist doof, weil die ganze Einladungslogistik dadurch gestört ist. Dann schon lieber migrieren ;-)

    Das ÖO-Setup per se ist nicht komplizierter geworden, im Gegenteil. Das neue System ist ja nicht so flexibel wie das alte, daher auch weniger kompliziert zu betreiben.

    Und "Server aus der DAG gefummelt" gibt es nicht. Eine DAG mit 2010er und 2016er Servern kann es eh nicht geben, daher neue DAG, Postfach-Umzug, ÖO-Umzug, alte DAg auflösen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 13. August 2019 19:41
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    in 2003/2007 gab es noch keine DAG ;-)

    Wenn alle Server nebeneinander stehen und das Restore vom Backup als Hochverfügbarkeit reicht, musst Du nicht mehrere ÖO-DBs haben und auch nicht mehrere Replikate pflegen.

    Die Komplexität der Migration hat damit keinerlei Bewandtnis. Es ist und bleibt der Wechsel von der alten auf die neue Architektur mit allen Schritten, die nötig sind.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 14. August 2019 11:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Zusätzlich zu Evgenij,
    wir haben die Prozedur letztes JAhr vollzogen und  ehrlich, wenn du nicht unbedingt die 2010er Public Folder vorher brauchst, dann lass es. Die Migration macht nicht wirklich Spaß. Und nein, die Replikationtopology vererbt sich nicht, aber es gibt Tools/Skripte die das für einen machen.

    Mittwoch, 14. August 2019 13:00
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ad 1. nein, es sind dann auf jedem Server 4 Kopien von Postfach-DB (aktiv oder passiv) plus eine PF-DB gehostet.

    ad 2. ja, die Replikation findet in der alten Public Folder-Architektur pro Ordner statt, daher muss der Ordner natürlich da sein, bevor man die Replikation aktivieren kann ;-) Dafür sind aber alle Replikate lesbar und schreibbar. Hat in Umgebungen mit schlechtem WAN gewisse Vorteile gegenüber der neuen Methodik ;-)

    ad 3. indem Du einem Ordner Replikate in weiteren DBs hinzufügst.

    ad 4. Wenn Du in jeder PF-DB ein Replikat von jedem PF (PF hier = "Public Folder", nicht "Postfach") hast, brauchst Du ja auch nur eine zu sichern ;-)

    ad 5. Migration auf 2016 --> ich würde zuerst migrieren, dann stellen sich all die Fragen nicht mehr. Und die PF-Migration von alt auf neu ist nichts für schwache Nerven.

    ad 6. Mist, gestern hätte ich einfach mal rasch nachschauen können.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 13. August 2019 17:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Evgenij,

    >ad 2. ja, die Replikation findet in der alten Public Folder-Architektur pro Ordner statt, daher muss der Ordner natürlich da sein, bevor man die Replikation aktivieren kann ;-) Dafür sind aber alle Replikate lesbar und schreibbar. Hat in Umgebungen mit schlechtem WAN gewisse Vorteile gegenüber der neuen Methodik ;-)

    Okay aber ich brauche dann nur den obersten Ordner in der Hierarchie anlegen, die darunter dann zB mit Outlook angelegten Ordner oder Kalender replizieren sich dann von selbst?

    >ad 3. indem Du einem Ordner Replikate in weiteren DBs hinzufügst.

    Ich habe hier ein ziemlich grausigen Video gefunden, wo das bebildert ist aber so grundsätzlich scheint das so zu funktionieren ... hoffentlich:

    https://www.youtube.com/watch?v=SN9AP1eCHjk

    >ad 5. Migration auf 2016 --> ich würde zuerst migrieren, dann stellen sich all die Fragen nicht mehr. Und die PF-Migration von alt auf neu ist nichts für schwache Nerven.

    Das wollte ich jetzt nicht hören :o

    Ich gehe aber davon aus, dass wir zuerst nur mit einem oder mehreren (wenn das möglich ist) Kalender(n) rechnen müssen. Wenn ich mal naiv an die Sache gehe, hoffe ich, dass man im Notfall die Kalender aus dem alten System exportieren und im neuen System wieder importieren kann, nachdem man die alten Server dann vollständig aus der DAG gefummelt hat. Eine etwaige Downtime der Kalender wäre sicherlich nicht das Problem. Könnte man das so als Rettungsschirm stehen lassen?

    Wenn das  ÖO Setup bis dahin grundsätzlich komplizierter geworden ist, muss man halt da durch aber da unterstützt uns dann eh ein Dienstleister bei der Migration. Der wird es dann schon wissen und so ein wenig sind es ja dann auch seine Nerven, auf die es ankommt... ;-)

    Thx & Bye Tom

    Dienstag, 13. August 2019 18:16
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    es ist schon länger her, aber ich meine mich zu erinnern, dass die Replikationstopologie sich nicht vererbt. 

    Das Video ist zwar für Exchange 2003, aber ja, genau so machst Du das auch in 2010.

    Kalender exportieren/importieren ist doof, weil die ganze Einladungslogistik dadurch gestört ist. Dann schon lieber migrieren ;-)

    Das ÖO-Setup per se ist nicht komplizierter geworden, im Gegenteil. Das neue System ist ja nicht so flexibel wie das alte, daher auch weniger kompliziert zu betreiben.

    Und "Server aus der DAG gefummelt" gibt es nicht. Eine DAG mit 2010er und 2016er Servern kann es eh nicht geben, daher neue DAG, Postfach-Umzug, ÖO-Umzug, alte DAg auflösen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 13. August 2019 19:41
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Evgenij,

    >Und "Server aus der DAG gefummelt" gibt es nicht. Eine DAG mit 2010er und 2016er Servern kann es eh nicht geben, daher neue DAG, Postfach-Umzug, ÖO-Umzug, alte DAg auflösen.

    Okay, das hatte ich anders abgespeichert. Wir hatten uns darüber schon mal zwischen Tür und Angel mit dem Dienstleister unterhalten und ich glaubte mich zu erinnern, dass das alles in einer DAG abgewickelt werden kann. Afair war das auch bei der Migration von 2003 auf 2010 der Fall, wobei damals ein Single Server 2003 Setup in eine neue 2010 DAG migriert wurde. Ist auch schon wieder eine Weile her ;-)

    Aber mal eine ganz andere Frage: Muss ich überhaupt die ÖO auf alle Server synchronisieren? Würde es nicht reichen das zB nur auf dem Server zu aktivieren, der auch gesichert wird? Zumindest bis zur Migration auf 2016? Innerhalb der Organisation, wo beide Server erreichbar sind, wird das vermutlich egal sein, es sollte ja im AD stehen, wo die ÖO-DB liegt. Wie verhält sich das dann aber mit den Clients, die sich extern befinden und vom Internet aus via HTTPS nur einen Server erreichen können, der dann dummerweise nicht der ist, der gesichert wird und damit auch nicht der ist, der die ÖO hosten würde? Vermittelt der dann zwischen ÖO Host und Client? Note: Auf beiden Servern sind die Rollen CAS und Hub-Transport installiert.

    Last but not least bliebe dann noch die Frage, ob mir das überhaupt was bringt, hinsichtlich Komplexität und Migration, dass ganze nur auf einem Server zu aktivieren?

    Thx & Bye Tom


    Dienstag, 13. August 2019 20:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    in 2003/2007 gab es noch keine DAG ;-)

    Wenn alle Server nebeneinander stehen und das Restore vom Backup als Hochverfügbarkeit reicht, musst Du nicht mehrere ÖO-DBs haben und auch nicht mehrere Replikate pflegen.

    Die Komplexität der Migration hat damit keinerlei Bewandtnis. Es ist und bleibt der Wechsel von der alten auf die neue Architektur mit allen Schritten, die nötig sind.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 14. August 2019 11:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Zusätzlich zu Evgenij,
    wir haben die Prozedur letztes JAhr vollzogen und  ehrlich, wenn du nicht unbedingt die 2010er Public Folder vorher brauchst, dann lass es. Die Migration macht nicht wirklich Spaß. Und nein, die Replikationtopology vererbt sich nicht, aber es gibt Tools/Skripte die das für einen machen.

    Mittwoch, 14. August 2019 13:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Evgenij,

    >Die Komplexität der Migration hat damit keinerlei Bewandtnis. Es ist und bleibt der Wechsel von der alten auf die neue Architektur mit allen Schritten, die nötig sind.

    Wir haben jetzt mal auf einem Server einen öffentlichen Ordner angelegt und darin über Outlook einen Kalender zum Testen angelegt. Es waren alle getesteten Variationen (Unterkalender im Kalender des Benutzers, den kompletten Benutzer Kalender freigeben und Öffentlicher Kalender) nicht ohne Probleme, so dass wir uns jetzt bis auf Weiteres auf das Freigeben eines Benutzerkalenders geeinigt haben. Die ÖO sind demnach erst mal nicht notwendig.

    Frage hinsichtlich der bereits angelegten Public Folder Database: Können wir die jetzt einfach wieder löschen und die Migration läuft dann so als ob niemals eine da gewesen wäre oder gräbt sich die irgendwo tief ins AD und bleibt da als quasi als Zombi-Objekt bis in alle Ewigkeit und macht uns weiter Schwierigkeiten? Weil dann würde ich die ÖO DB einfach wieder löschen, eine Replikation war auch noch keine eingerichtet.

    Thx & Bye Tom 

    Mittwoch, 14. August 2019 13:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus,

    >[...]Die Migration macht nicht wirklich Spaß[...]

    Ja wir haben uns jetzt erst mal bis auf Weiteres auf das Freigeben eines Benutzerkalenders geeinigt und greifen das Thema Öffentliche Ordner nach der Migration wieder auf. Wir haben jetzt nur schon eine Datenbank für öffentliche Ordner zum Testen angelegt, hoffentlich kann ich das ganze wieder rückstandslos entfernen?

    Thx & Bye Tom


    Mittwoch, 14. August 2019 13:46
    |