de-DEen-GB
 
rss

Granikos Technology Blog

Und weiter einmal...

Die neue Version von .Net Framework wurde veröffentlicht und von Microsoft per Windows Update bereitgestellt. Das Exchange Team wiederum hat sich überlegt, die Version 4.7.2 nicht offiziell zu unterstützen. Das bedeutet, dass Sie .Net Framework 4.7.2 auf Exchange Server Systemen nicht installieren dürfen. 

Da die Verteilung per Windows Update erfolgt, müssen Sie die Installation per Registrierungsschlüssel auf jedem Exchange Server blockieren. 

Mit der folgenden BlockNetFramework472.reg Datei können Sie den Registrierungsschlüssel schnell und einfach setzen.

 

Links

 

Weiterhin Viel Spaß mit Exchange Server!

Weiterlesen »

Die Inhalte aktueller Microsoft Produktversionen werden vom TechNet zu Microsoft Docs migriert.

Ab sofort sind die Inhalte für Exchange Server 2016 bei Microsoft Docs verfügbar und ermöglichen einen moderneren Zugriff auf die Informationen. Die Informationen bei Microsoft Docs stellen die aktuelle Dokumentation für Exchange Server 2016 dar.

Exchange Server 2016 Dokumentation bei Microsoft Docs

DIe Inhalte der Vorversionen von Exchange Server sind teilweise bereits bei Microsoft Docs verfügbar oder liegen noch im Microsoft TechNet. Jedoch werden die Informationen zu den Vorversionen von Exchange Server nicht mehr aktualisiert.

Links

 

Viel Spaß.

Weiterlesen »

Mit der E-Mail Gateway Lösung NoSpamProxy können Sie leicht mehrere Office 365 Tenats mit einer Gateway-Lösung verbinden. Die Gründen für solch ein Szenario können vielfältig sein. Hierzu gehören Unternehmensfusionen, aber auch Abspaltungen, rechtliche oder betriebliche Erfordernisse zur Trennung der Datenspeicherung. 

Für das Szenario in diesem Blog Post

  • Es existiert bereits eine Office 365 Global Verbindung zwischen dem E-Mail Gateway und Exchange Online
  • Es soll ein neuer Tenant in Office 365 Deutschland erstellt und an das Gateway angebunden werden
  • E-Mail-Empfänger nutzen eine separate Domäne im neuen Tenant

Der neue Office 365 Deutschlang Tenant wurde bereits erstellt und die benutzerdefinierte Domäne ebenfalls registriert. Hierbei hat sich gezeigt, dass es möglich ist in beiden Umgebungen den gleichen Tenantnamen zu verwenden. Micosoft prüft bei der Registrierung nicht, ob der Tenantname bereits in einer anderen Office 365 Umgebung verwendet wird. Allerdings wird innerhalb des Admin Centers von Office 365 Deutschland bei der Registrierung der benutzerdefinierten Domäne ein Abgleich vorgenommen. Sie können eine benutzerdefinierte Domäne nur einmal über alle Office 365 Plattformen hinweg registrieren. Das in diesem Post beschriebene Beispiel funktioniert ebenso für zwei oder mehr Tenants in Office 365 Global.

Ausgangssituation für die Konfiguration:

  • Office 365 Global
    • Tenant: granikos.onmicrosoft.com
    • Benutzerdefinerte Domäne: granikos.eu
  • Office 365 Deutschland
    • Tenant: granikos.onmicrosoft.de
    • Benutzerdefinierte Domäne: granikoslabs.eu

Zielumgebung

Das folgende Diagramm verdeutlicht das Setup mit NoSpamProxy und zwei Office 365 Tenants (Global/DE).

NoSpamProxy mit zwei Office 365 Tenant Anbindungen

  • E-Mail-Nachrichten von externen Empfängern werden über die MX-Einträge in den öffentlichen DNS-Zonen der Domänen zu NoSpamProxy geroutet
  • NoSpamProxy führt eine Anti-Spam und Anti-Malware Filterung und ggf. eine E-Mail-Entschlüsselung durch
  • Angenommene Nachrichten für gültige Empfänger werden durch NoSpamProxy zum passenden Tenant geroutet und dort ins Empfängerpostfach zugestellt
  • Ausgehende Nachrichten werden von den Absendern im Postfach erstellt und durch Exchange Online zu NoSpamProxy geroutet
  • NoSpamProxy führt weitere Aktionen, wie z.B. E-Mail-Verschlüsselung oder das Hinzufügen einer E-Mail-Signatur, durch
  • NoSpamProxy stellt die Nachrichten auf Basis der MX-Einträge der Empfängerdomänen durch
  • Empfänger des primären Tenants in Office 365 Global (mit AAD Connect Synchronisierung) werden von NoSpamProxy direkt aus dem lokalen AD synchronisisert
  • Empfänger des sekundären Tenants in Office 365 Deutschland werden von NoSpamProxy aus einer lokalen Textdatei synchronisisert

 

Konfiguration

Die nachfolgenden Schritte beschreiben die Konfiguration des NoSpamProxy Gateways über die NoSpamProxy Management Oberfläche der Intranet-Rolle.

Schritt 1: Hinzufügen der Domänen

Fügen Sie sowohl die Domäne des Office 365 Deutschland Tenants und die benutzerdefinierte Domäne als Ihnen gehörende Domänen (Owned domains) hinzu. Ohne diesen Schritt können Sie die Domänen weder einem E-Mail-Server des Unternehmens oder Empfänger mit einer dieser Zieldomänen hinzufügen.

Hinzufügen der Domänen

 

Schritt 2: Office 365 Deutschland Tenant in Exchange Online DE hinzufügen

Fügen Sie einen neuen E-Mail-Server (Corporate email servers) hinzu und wählen Sie den den Typ As Office 365 tenant aus.

Office 365 DE Tenant als E-Mail Server des Unternehmens hinzufügen

Wählen Sie als Endpunkt German Azure Cloud aus und geben Sie den Tenantnamen des Office 365 Deutschland Tenants ein.

Tenant in der Deutschland Cloud konfigurieren

Ordnen Sie nun die beiden in Schritt 1 hinzugefügten Domänen der neuen E-Mail-Server Konfiguration zu.

Zuordnung der Domänen zum Office 365 Deutschland Tenant

Geben Sie bei Bedarf einen individuellen Kommentar ein und schließen Sie die Konfiguration ab.

Abschluss der E-Mail-Server Konfiguration

Nach erfolgter Konfiguration sind beide Tenants in der Übersicht sichtbar.

Übersicht der E-Mail Server Konfiguration für beide Office 365 Tenants

 

Schritt 3: E-Mail Adressen importieren

Die Empfänger mit E-Mail-Adressen im Office 365 Deutschland Tenant werden von NoSpamProxy aus einer Textdatei importiert. Hierzu ist ein regelmäßiger Import in der NoSpamProxy MMC konfiguriert. Diese Adressen werden nur importiert, wenn die E-Mail-Domäne in Schritt 1 als eigene Domäne korrekt konfiguriert wurde.

Kontrolle der Office 365 Deutschland Empfänger

Es wird nur die E-Mail-Adresse importiert. Der Import weiteren Benutzerinformation, wie z.B. Vorname und Nachname, ist eine der weitere Aufgaben in diesem Projekt.

 

Voraussetzungen

Das in diesem Blog Post gezeigte Beispiel erfordert NoSpamProxy in der Version 12.2.18094.7 oder höher, wenn der Tenantname in Office 365 Global und Office 365 Deutschland identisch sind. Sind beide Namen unterschiedliche, kann auch eine aktuelle Version 12.1 eingesetzt werden.

 

Aufgaben

Die beschriebene Konfiguration bietet erst einmal eine funktionsfähige Umgebung, ist aber für den Regelbetrieb in einem Unternehmen noch nicht optimal. In den nächsten Artikeln zur Anbindung an mehere Tenants werde ich folgenden Themen betrachten:

  • PowerShell Script zum Erstellen von Empfängerobjekten in NoSpamProxy auf Basis von Azure AD Daten
  • Konfiguration der Umgebung, um Empfänger unter einer Empfangsdomäne auf zwei oder mehr Tenants zu verteilen 

 

Links

 

Viel Spaß mit Office 365 und NoSpamProxy.

Sie haben weitere Fragen zur beschriebenen Konfiguration? Kontaktieren Sie mich gerne per E-mail: thomas@mcsmemail.de.

 

 

Weiterlesen »
Dies ist die deutschsprachige Version meines Blog Posts The Right Exchange Architecture im ESE Blog von ENow


 

Warum gibt es die Preferred Architecture?

Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.

Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:

Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.

Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.

Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.

Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.

Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.

Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.

Do Exchange Right

Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?

  • Standardisiert
    Exchange Online bietet eine standardisierte Nutzung von Exchange Server Funktionen im Rahmen des Software-as-a-Service Angebotes von Office 365. Hierbei nutzen Sie nur die Funktionen von Exchange und haben keinerlei direkten Zugriff auf die Server Systeme. Die gesamte Verwaltung des Betriebssystems und das Patchen von Exchange Server führt Microsoft für Sie durch. Sie können sich so ganz auf die Konfiguration Ihrer Exchange Online Organisation oder aber den Hybrid-Verbund mit Ihrer lokalen Exchange Organisation konzentrieren.
     
  • Strukturiert
    Die strukturierte Implementierung einer Exchange Server Plattform folgt der Preferred Architecture der Exchange Produktgruppe oder der Product Line Architecture, basierend auf den Empfehlungen und Erkenntnissen von Microsoft Architekten. Eine solche Implementierung ist, ebenso wie die Nutzung von Exchange Online, als Lösung für einen optimalen Betrieb anzusehen. Wie sich die Preferred Architecture im Detail darstellt wird weiter unten beschrieben.
     
  • Empfohlen
    Eine On-Premises Exchange Server Implementierung, die den Best Practices folgt, weicht in signifikanten Punkten von der Preferred Architecture ab und bietet trotzdem einen sicheren und stabilen Betrieb. Eine solche Abweichung ist z.B. der Betrieb auf einem Hypervisor, jedoch unter Anwendung der Betriebsparameter für den Betrieb von Exchange Server auf physikalischen Systemen (Stichwort: feste Ressourcenzuweisung). Der Exchange Server Best Practices Analyzer ist eine Click-To-Run Applikation, die direkt aus dem Exchange Admin Center einer On-Premises Implementierung heraus aufgerufen werden kann. Alternativ kann hierzu auch das Exchange Analyzer Script von Paul Cunningham aus der TechNet Gallery verwendet werden.
     
  • Unterstützt
    Eine unterstützte Implementierung von Exchange Server weicht in zahlreichen Punkten von der Preferred Architecture ab, bewegt sich aber immer noch im durch Microsoft unterstützten Betrieb. Solch ein unterstützter Betrieb folgt den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen. Diese Art der Implementierung ist als absolutes Mindestmaß anzusehen.
     
  • Funktioniert (irgendwie)
    Natürlich kann man Exchange Server auch irgendwie zum Laufen bringen. Dies ist die letzte Kategorie. In diese Kategorie fallen Einzelserver Implementierungen unter Verwendung von redundanten Speichersystemen oder der grundsätzlich Betrieb von Exchange Server mit nicht unterstützten Speichersystemen (siehe Exchange Server Speicherkonfigurationsoptionen). In diesem Bereich fallen aber auch Exchange Server Implementierung auf AWS oder Microsoft Azure ohne Premium Storage. Ihre produktive Exchange Server Plattform sollte nicht zu dieser letzten Kategorie gehören, da Sie ansonsten ein unnötig hohes Betriebsrisiko eingehen.

 

Was ist die Preferred Architecture?

Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.

Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.

Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.

Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:

  • Namensraum-Design
  • Rechenzentrumsdesign
  • Server-Design
  • DAG-Design

Namensraum-Design

Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden. 

Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.

Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.

Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.

Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:

  1. AutoDiscover Endpunkt: autodiscover.varunagroup.de
  2. Client Endpunkt für alle Exchange Dienste: mail.varunagroup.de
  3. Office Online Server Endpunkt Rechenzentrum A: oos-a.varunagroup.de
  4. Office Online Server Endpunkt Rechenzentrum B: oos-b.varunagroup.de

Exchange Server Preferred Architecture Design
 

Rechenzentrumsdesign

Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.

Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.

Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:

  • Die Funktionen für einen ausfallsicheren Betrieb des E-Mail Transports mit Shadow Redundancy und Saftety Net
  • Der Active Directory Design Empfehlung folgend müssen Netzwerkesegmente mit einer Gesamtlaufzeit von mehr als 10ms in separaten Active Directory Site platziert werden

Server-Design

In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:

  • Jeder Server ist für eine 80% Auslastung bei größtmöglichem Ausfallszenario berechnet
  • Virtualisierung stellt eine zusätzliche Komplexität im Falle einer Wiederherstellung dar, die keinerlei Vorteil bringt (siehe auch Hauptgrundsatz von Exchange Server)

Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:

  • 2HE Server, Dual-Sockel mit 20-24 Prozessorkernen
  • Maximal 192GB Arbeitsspeicher
  • Festplattencontroller mit Batterie-abgesichertem Schreib-Cache
  • 12 oder mehr Festplatteneinschübe im Servergehäuse

Die weiteren Konfigurationen des Servers sind:

  • Einzelner RAID1 Verbund aus zwei Festplatten für das Betriebssystem, Exchange Server Installation, Protokolldateien und Transportdatenbanken
  • Alle weiteren SAS Festplatten sind als JBOD konfiguriert
  • Dateisystem für Datenlaufwerke ist ReFS
  • Schutz der Daten durch BitLocker Festplattenverschlüsselung
  • Absicherung gegen Festplattenausfall durch DAG AutoReseed

 

DAG-Design

Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.

Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert. 

DAG Netzwerkdesign

In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.

Witness Server

Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.

 

Zusammenfassung

Was ist nun die richtige Exchange Server Architektur?

Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.

Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.

Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.


Abkürzungen

  • PA | Preferred Architecture
  • PLA Product Line Architecture

Links

 

Viel Spaß beim Betrieb von Exchange Server.

 

Weiterlesen »

Anfang Juli habe ich einen Workshop zum Thema Planung und Implementierung eines Upgrade zu Exchange Server 2016 gehalten. 

Die im Workshop verwendte Präsentation steht seit heute bei Slideshare zum Download bereit. Neben dem technischen Teil gab es auch Themenblöcke mit freier Diskussion. Diese sind natürlich nicht Bestandteil der Präsentation.

 

Viel Spaß mit Exchange Server 2016.

 


Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Plattform? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu

 

 

Weiterlesen »