de-DEen-GB
 
rss

Granikos Technology Blog

aOS AachenAm 3. September 2018 finden das Treffen der aOS Community Aachen statt. Themenschwerpunkt ist Microsofts Moderne Zusammenarbeit 2.0.

Ich werde auf der Veranstaltung in zwei Sessions über die folgenden Themen sprechen:

  • Migrating Legacy Public Folders to Modern Public Folders
  • Modern Attachments with OneDrive

 

 

Agenda

aOS Aachen | Agenda

Weitere Informationen finden Sie auf der Veranstaltungsseite des aOS Events.

Links

 

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 »
On Januar 12, 2018
1003 Views

Problem

Wie kann ich eine Cloud-Only Shared Mailbox in Office 365 in eine AAD Connect synchronisierte User Mailbox konvertieren, deren Anmeldung anschließend über ADFS erfolgt?

Lösung

Verbinden Sie sich mit der Exchange Online PowerShell und prüfen Sie zuerst, ob das anzupassende Postfach vom Typ SharedMailbox ist. Dies erkennen Sie daran, dass das Attribut RecipientTypeDetails den Wert SharedMailbox hat.

Screenshot 1 - Konvertierung Cloud-Only SharedMailbox zu AD UserMailbox

Anschließend wird die Shared Mailbox in den Typ UserMailbox umgewandelt. Dies erfolgt mit Hilfe von

Set-Mailbox -Identity MAILBOXNAME -Type Regular 

Die erneute Prüfung zeigt den neuen RecipientTypeDetails Typ UserMailbox.

Screenshot 2 - Konvertierung Cloud-Only SharedMailbox zu AD UserMailbox

Nun wird im lokalen Active Directory (AD) der entsprechende User mit dem gleichen User Pricipal Name wie der Cloud-Only User neu angelegt.

Screenshot 3 - Konvertierung Cloud-Only SharedMailbox zu AD UserMailbox

Nachdem der neue Benutzer im AD erstellt ist, muss diesem nun die Default SMTP Adresse eingetragen werden. Die Adresse wird bei den User Attributen unter proxyAddresses eingetragen. Um die Attribute sehen und bearbeiten zu können, müssen in der Active Directory Users and Computers Management Console die Advanced Features aktiviert werden. 

Screenshot 4 - Konvertierung Cloud-Only SharedMailbox zu AD UserMailbox

Der Reiter Attribute Editor erscheint nur, wenn der entsprechende User in der OU aufgerufen wird, in dem er gespeichert ist. Wenn der User über die Such-Funktion aufgerufen wird, erscheint der Reiter leider nicht. Wo der User im AD liegt kann man im Reiter Object sehen.

Rufen Sie im Reiter Attribute Editor das Attribute proxyAddresses auf und tragen den entsprechenden SMTP Eintrag ein. Wichtig ist, dass SMTP in Großbuchstaben geschrieben wird. Nur dann ist es die Default oder primäre SMTP Adresse. In Kleinbuchstaben wäre es ein Alias bzw. eine zusätzliche Empfangsadresse und das passt nicht zum Eintrag in Office 365. AAD Connect matcht über die primäre SMTP Adresse.

Screenshot 5 - Konvertierung Cloud-Only SharedMailbox zu AD UserMailbox

Nach dem Speichern des Eintrages muss der AAD Connect Sync abgewartet werden und dem User in Office 365 noch eine passende Lizenz zugewiesen werden, damit die Mailbox auch aktiv wird.

Viel Spaß mit Office 365


Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption | E-Mail Security Made in Germany | Wir beraten Sie gerne: info@granikos.eu

 

 

Weiterlesen »

Logo Exchange User Group Berlin

Am 22. Februar 2018 findet das erste Treffen der Exchange User Group Berlin in diesem Jahr statt. Das Treffen findet in den Räumlichkeiten vom Microsoft Accelerator Berlin statt.

Agenda

  • Allgemeines und Planung
  • Office 365 Compliance Solutions mit Rainer Seegatz (Microsoft)
  • Bessere Zusammenarbeit mit OneDrive for Business – Moderne Dateianhänge mit Exchange 2016 und Office 365 von Thomas Stensitzki
  • Zwangsloser Austausch in der Runde

Die Anmeldung erfolgt über die Webseite der Exchange User Group Berlin

Wir sehen uns.

 

 

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 »