none
AD-Site sinnvoll bei Exchange 2016 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    mich beschäftig gerade folgende Frage zum Thema AD/Net-Site für Exchange 2016.

    Wir haben bei uns im RZ ein RZ-Netzwerk für die Server, wo aktuell auch unsere Exchange Server 2010 verortet sind. Im Zuge der Planung für Exchange 2016 haben Wir uns für den Einsatz einer KEMP innerhalb des Netzwerkes entschieden (Extern kommt es über eine Sophos rein). Um Auswirkungen auf unsere produktiven Exchange Umgebung zu minimieren, haben Wir ein neues Netzwerksegment (VLan) nur für die Exchange Server 2016 erstellt, welches in das RZ-Netz vollständig geroutet ist. In diesem Netzwerk (Exchange VLan) steht auch ein DC (Empfehlung unseres externen Beraters).

    Ich habe damals eine neue AD-Site (RZ_Exchange-2016) erstellt und bin mir nun nicht mehr sicher, ob dies sinvoll ist, gerade wenn man die Replikationen der DC innerhalb des RZ betrachtet. Wir haben zwar das Replikationsinntervall auf das Minimum (glaube 15 min) gestellt aber ich bin mir da nicht so sicher, ob das im späteren produktiven Betrieb nach der Migration so richtig ist. Die KEMP bei uns hat einen Fuß im RZ und einen im RZ-Exchange Netz und die Clients würden so auch mit den Exchange Servern kommunizieren.

    Mein Frage:

    Ist es sinnvoll eine AD-Site in unserem Fall (bzw. generell) nur für die Exchange Server 2016 zu erstellen, oder reicht ein separates Netzwerk völlig aus. Des Weiterem steht bei uns die Frage im Raum, ob der DC ein Muss ist (laut Berater sinnvoll falls das Routing mal nicht funktioniert und so die ExSvr weiter laufen und einen DC im Netz haben).

    Ps.: Falls Ihr Artikel zum Thema Exchange und DC in einem Netz habt, bitte teilt mir diese mit.

    Ich danke vorab für Eure Hinweise ;-)

    Mit freundlichen Grüßen

    Paul (Berlin)




    • Bearbeitet Lexxitus Montag, 21. Mai 2018 17:01
    Montag, 21. Mai 2018 16:59
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    das sind sehr viele Fragen auf einmal. Ich versuche es mal:

    1. wenn zwischen zwei AD Sites ein LAN ist, also keine Latenzen oder Bandbreitenbeschränkungen vorliegen, kann man die Replikation auch auf das gleiche Verfahren wie innerhalb einer Site umstellen, Stichwort USE_NOTIFY.
    2. In jeder AD-Site, wo ein Exchange-Server steht, ist ein RWDC Pflicht, alles andere ist nicht supportet.
    3. Eine separate Site nur für Exchange ist im Betrieb vermutlich nicht nur nicht förderlich, sondern sogar hinderlich, wobei ich solche Konstruktionen durchaus schon mehrmals gesehen habe. Was Sinn macht, ist eine Installationssite für neu, noch nicht fertig konfigurierte Exchange Server. Zu dieser muss die Replikation so gewichtet werden, dass die Clients im Normalfall nicht versuchen werden, dorthin zu verbinden.
    4. Ein separates Subnetz nur für Exchange kann, muss aber nicht, Sinn machen. Wichtig ist, dass sich das in das allgemeine Netzwerk(sicherheits)Konzept einfügt, damit die Betriebsprozesse funktionieren. Macht ihr für jedes Fachverfahren ein eigenes Subnetz, dann macht es halt auch für Exchange, ansonsten eher nicht. Wenn dabei der Fall "falls das Routing mal nicht funktioniert" potentiell wahrscheinlich ist, dann sollte in der Tat ein DC in diesem Netz stehen. Allerdings wird im RZ das Routing meistens auf den Core-Switchen ausgeführt, und wenn DAS nicht funktioniert, ist Exchange vermutlich eh isoliert, DC oder nicht.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Lexxitus Dienstag, 22. Mai 2018 09:07
    Montag, 21. Mai 2018 19:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    noch drei Ergänzungen:

    1. Best-Practise wären mindestens zwei DC in einer Site, in der Exchange steht. Eine reine Exchange-Site halte ich aber auch für übertrieben.

    2. Auch eine reine Exchange-Installations-Site macht nur Sinn, wenn man sehr oft Exchange-Server installiert. Passiert das nur bei einer Migration oder höchstens im Desaster-Fall mal, nutze ich dafür dieses Script:

    http://www.expta.com/2016/07/new-set-autodiscoverscp-v2-script-is-on.html

    Das wird vor der Installation auf einem laufenden Exchange gestartet und wartet in einer Schleife so lange, bis die entsprechenden AD-Attribute für den neuen Server auftauchen. Das passier relativ weit am Ende des Setups. Dann hat man effektive nur für sehr kurze Zeit (< 1 Sekunde) falsche Einstellungen im AD.

    3. Zum KEMP-Loadbalancer: Aus technischen Gründen arbeitet das Loadbalancing auf Layer 7 immer per NAT. Als Ergebnis sieht man in den Exchange Logs also nicht mehr die "echte" Client-IP-Adresse, sondern nur noch die des Loadbalancers. Das ist bei SMTP blöd, wenn man verschiedene Connectoren über die Remote IP steuern will und sich einliefernde Server im gleichen Netzwerksegment befinden, wie Exchange.

    Hierfür baut man entweder ein eigenes Netzwerksegment auf, in dem der Loadbalancer dann auch Gateway spielt. Das ist administrativ ein wenig aufwendiger (z.B. wenn man Backup-Traffic anders routen möchte), aber netzwerktechnisch sauber. Oder es wird "Direct Server Return" genutzt. Das bedeutet dann aber Load Balancing auf Layer 4. Hierbei wird das IP-Paket vom Loadbalancer so umgeschrieben, dass zwar die IP-Adresse im Packet weiterhin die vom LB ist, die MAC-Adresse ist aber die vom Exchange Server, an den das Paket geht. Hierzu muss ein Loopback-Adapter mit besonderen Einstellungen auf den Exchange Server installiert werden. Das Antwortpaket geht dann am LB vorbei direkt zum ursprünglichen Server. Das sieht netzwerktechnisch merkwürdig aus, ist aber eigentlich nichts anderes, als es ein Gateway/Router macht (nur "umgekehrt").

    Anleitungen zu beidem findet man auf der Homepage von KEMP.

    Wir nutzen bei uns eine Mischung aus beidem: HTTP/POP/IMAP -> L7 & NAT; SMTP -> L4 & DSR.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert Lexxitus Dienstag, 22. Mai 2018 09:08
    Dienstag, 22. Mai 2018 07:13
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    das sind sehr viele Fragen auf einmal. Ich versuche es mal:

    1. wenn zwischen zwei AD Sites ein LAN ist, also keine Latenzen oder Bandbreitenbeschränkungen vorliegen, kann man die Replikation auch auf das gleiche Verfahren wie innerhalb einer Site umstellen, Stichwort USE_NOTIFY.
    2. In jeder AD-Site, wo ein Exchange-Server steht, ist ein RWDC Pflicht, alles andere ist nicht supportet.
    3. Eine separate Site nur für Exchange ist im Betrieb vermutlich nicht nur nicht förderlich, sondern sogar hinderlich, wobei ich solche Konstruktionen durchaus schon mehrmals gesehen habe. Was Sinn macht, ist eine Installationssite für neu, noch nicht fertig konfigurierte Exchange Server. Zu dieser muss die Replikation so gewichtet werden, dass die Clients im Normalfall nicht versuchen werden, dorthin zu verbinden.
    4. Ein separates Subnetz nur für Exchange kann, muss aber nicht, Sinn machen. Wichtig ist, dass sich das in das allgemeine Netzwerk(sicherheits)Konzept einfügt, damit die Betriebsprozesse funktionieren. Macht ihr für jedes Fachverfahren ein eigenes Subnetz, dann macht es halt auch für Exchange, ansonsten eher nicht. Wenn dabei der Fall "falls das Routing mal nicht funktioniert" potentiell wahrscheinlich ist, dann sollte in der Tat ein DC in diesem Netz stehen. Allerdings wird im RZ das Routing meistens auf den Core-Switchen ausgeführt, und wenn DAS nicht funktioniert, ist Exchange vermutlich eh isoliert, DC oder nicht.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Lexxitus Dienstag, 22. Mai 2018 09:07
    Montag, 21. Mai 2018 19:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    noch drei Ergänzungen:

    1. Best-Practise wären mindestens zwei DC in einer Site, in der Exchange steht. Eine reine Exchange-Site halte ich aber auch für übertrieben.

    2. Auch eine reine Exchange-Installations-Site macht nur Sinn, wenn man sehr oft Exchange-Server installiert. Passiert das nur bei einer Migration oder höchstens im Desaster-Fall mal, nutze ich dafür dieses Script:

    http://www.expta.com/2016/07/new-set-autodiscoverscp-v2-script-is-on.html

    Das wird vor der Installation auf einem laufenden Exchange gestartet und wartet in einer Schleife so lange, bis die entsprechenden AD-Attribute für den neuen Server auftauchen. Das passier relativ weit am Ende des Setups. Dann hat man effektive nur für sehr kurze Zeit (< 1 Sekunde) falsche Einstellungen im AD.

    3. Zum KEMP-Loadbalancer: Aus technischen Gründen arbeitet das Loadbalancing auf Layer 7 immer per NAT. Als Ergebnis sieht man in den Exchange Logs also nicht mehr die "echte" Client-IP-Adresse, sondern nur noch die des Loadbalancers. Das ist bei SMTP blöd, wenn man verschiedene Connectoren über die Remote IP steuern will und sich einliefernde Server im gleichen Netzwerksegment befinden, wie Exchange.

    Hierfür baut man entweder ein eigenes Netzwerksegment auf, in dem der Loadbalancer dann auch Gateway spielt. Das ist administrativ ein wenig aufwendiger (z.B. wenn man Backup-Traffic anders routen möchte), aber netzwerktechnisch sauber. Oder es wird "Direct Server Return" genutzt. Das bedeutet dann aber Load Balancing auf Layer 4. Hierbei wird das IP-Paket vom Loadbalancer so umgeschrieben, dass zwar die IP-Adresse im Packet weiterhin die vom LB ist, die MAC-Adresse ist aber die vom Exchange Server, an den das Paket geht. Hierzu muss ein Loopback-Adapter mit besonderen Einstellungen auf den Exchange Server installiert werden. Das Antwortpaket geht dann am LB vorbei direkt zum ursprünglichen Server. Das sieht netzwerktechnisch merkwürdig aus, ist aber eigentlich nichts anderes, als es ein Gateway/Router macht (nur "umgekehrt").

    Anleitungen zu beidem findet man auf der Homepage von KEMP.

    Wir nutzen bei uns eine Mischung aus beidem: HTTP/POP/IMAP -> L7 & NAT; SMTP -> L4 & DSR.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert Lexxitus Dienstag, 22. Mai 2018 09:08
    Dienstag, 22. Mai 2018 07:13
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Robert, hallo Evgenij,

    vielen Dank für eure Antworten.

    Ich ziehe es auch in Betracht die AD-Site aufzulösen. Habt Ihr einen MS-Artikel wo das mit den DC innerhalb vom Exchange Netz zu finden ist? Anscheinend suche ich falsch ;-)

    Dienstag, 22. Mai 2018 07:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Habt Ihr einen MS-Artikel wo das mit den DC innerhalb vom Exchange Netz zu finden ist? Anscheinend suche ich falsch ;-)

    In den System Requirements für 2007, 2010 und 2013 stand noch der folgende Text:

    An jedem Active Directory-Verzeichnisdienststandort, an dem Sie Exchange 20## installieren möchten, muss mindestens ein globaler Katalogserver vorhanden sein...

    In 2016 findet sich dieser Passus tatsächlich nicht mehr, aber ich würde mich nicht davon täuschen lassen :-) Vielmehr würde ich erwarten, dass man Exchange 2016 in einer Site ohne RWDC / GC gar nicht erst installieren kann.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 22. Mai 2018 08:07
    |
  • Question
    Anmelden
    0
    Anmelden
    > Vielmehr würde ich erwarten, dass man Exchange 2016 in einer Site ohne RWDC / GC gar nicht erst installieren kann.

    So ist es. Habe ich bei unserer Migration mal ausprobiert, das Setup verweigert eine Installation in einer Site, in der sich kein GC befindet.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 22. Mai 2018 09:01
    |