Die beiden MVP-Kollegen Hans Brender und Raphael Köllner sind Gastgeber des MVP Kaffeeklatsch, einer Podcast/Videocast-Reihe rund um aktuelle Themen aus der IT
Ich war Gast in der aktuellen Folge 32 und wir haben uns in gemütlicher Runde über Exchange, Microsoft 365 und Remote Work unterhalten.
Viel Spaß.
Seit dem 11. September 2017 besteht für Office 365 Kunden die Möglichkeit, Gastkonten für externe Benutzer zu Microsoft Teams hinzuzufügen.
Der Zugriff für Gäste muss ebenfalls lizensiert werden. Hierzu muss in der Microsoft Teams Verwaltung im Office 365 Admin Portal der Lizentyp Gast aktiviert.
Hinweis aus der Office 365 Benachrichtigung im Admin Portal:
When we make this change, the ‘Pick the license you want to configure’ setting in ‘Settings > Services and Add-ins > Microsoft Teams’, will now have an option for ‘Guest’ with a default value of “off” for the ‘Turn Microsoft Teams on or off for your entire organization’ setting.
Die Aktivierung wird gerne übersehen.
Viel Spaß mit Office 365!
Das E-Mail-Sicherheitsgateway NoSpamProxy untertützt die Anbindung an die De-Mail-Infrastruktur. Mit Hilfe von De-Mail ist eine gesetzlich geregelte Zustellung von rechtlich relevanten E-Mail-Nachrichten möglich. MIt Hilfe von NoSpamProxy kann Ihr Unternehmen E-Mail-Nachrichten mit De-Mail-Empfängern austauschen, ganz unabhängig davon, ob Ihre E-Mail-Server in der internen IT-Infrastruktur betrieben werden oder als SaaS-Dienst wie z.B. Office 365. In meinem Beispiel befinden sich alle Postfächer in Exchange Online.
Die Anbindung von De-Mail und Office 365 über das E-Mail-Gateway wird im nachfolgenden Schaubild deutlich.
Die zur Anbindung an Office 365 erforderlichen Komponenten, wie z.B: Azure AD Connect, sind im Diagramm nicht dargestellt, um die Übersichtlichkeit zu gewährleisten.
Das E-Mail-Gatewaysystem wird in diesem Beispiel auf einer Hyper-V-Plattform betrieben. Da die De-Mail-Zertifikate auf einer Smardcard gespeichert sind und der Betrieb des Gateways unbeaufsichtigt erfolgen soll, muss die Smartcard über einen zertifizierten Kartenleser permanent eingebunden werden. Entsprechende Smartcard-Lesegeräte sind als USB-Geräte erhältlich. Beim Erwerb einer De-Mail-Signaturkarte erhalten Sie einen passenden Kartenleser.
Die Verbindung des physikalischen Smartcard-Lesegerätes zum virtualisierten Betriebssystem erfolgt mit Hilfe eines USB-Servers. Für diesen USB-Server wird auf dem virtualisierten Betriebssystem eine Treiber-Software installiert, die einen virtualisierten USB-Port bereitstellt. Über diesen vUSB-Port ist anschließend das Smartcard-Lesegerät mit dem Betriebssystem verbunden. Zusätzlich werden noch die passenden Treiber und die Verwaltungssoftware für das De-Mail-Zertifikat benötigt.
Das folgende Schaubild verdeutlicht die technische Anbindung des Smartcard-Lesegerätes mit einem virtualisierten Betriebssystem.
System-Komponenten
Software-Komponenten
Die Anbindung an De-Mail erfolgt immer auf einem NoSpamProxy-System mit installierter Gateway-Rolle. Ob es sich um ein reines Gateway-System handelt oder aber um ein System mit installierte Intranet- und Gateway-Rolle ist unerheblich. In der nachfolgenden Beschreibung gehe ich davon aus, dass die NoSpamProxy Gateway-Software bereits installiert ist und die Nutzung von De-Mail lizensiert ist.
Installieren Sie zuerst den USB-Server und richten Sie das Smartcard-Lesegerät im Windows Server Betriebssystem ein. Die in diesem Artikel beschriebenen Schritte und zu installierenden Komponenten gelten für Windows Server 2012R2 und Windows Server 2016 identisch. Für Windows Server 2019 liegen noch keine Erfahrungen vor.
An diesem Punkt haben Sie das Smartcard-Lesegerät über den USB-Server und den virtuellen USB-Treiber der USB-Umlenkung mit dem Windows Server Betriebssystem verbunden. Bei jedem Neustart des Betriebssystems wird das Lesegerät automatisch verbunden.
Für die folgenden Installationsschritte und die Einbindung des De-Mail-Zertifikates ist es erforderlich, dass Sie eine Konsolenverbindung zum virtualisierten Betriebssystem herstellen. Die Einbindung des Smartcard-Zertifikates innerhalb einer RDP-Sitzung auf dem Windows Server nicht möglich, da dies durch den Windows Smartcard-Treiber aktiv verhindert. Sie erkennen dies daran, dass es beim Start des TCOS-CardManagers zu folgender Fehlermeldung kommt.
In einer VMware Hypervisor-Plattform ist der Zugriff über eine Konsolensitzung kein Problem. Wenn Sie aber Hyper-V als Hypervisor-Plattform einsetzen, müssen Sie auf die folgenden Einstellung des Hyper-V-Hostsystems achten.
Die Funktion "Erweiterten Situngsmodus zulassen" muss ausgeschaltet sein. Wenn diese Funktion eingeschaltet ist, werden alle Sitzungen durch das Gast-Betriebssystem als RDP-Sitzungen wahrgenommen. Dies führt automatisch dazu, dass der beschriebene Zugriff auf die Smartcard-Blibliotheken unterbunden wird. Diese Funktion muss nur für den Zeitraum der Konfiguration der De-Mail-Zertifikate in Windows Server ausgeschaltet sein bzw. immer dann, wenn Sie mit dem TCOS CardManager arbeiten müssen.
Folgende Schritte sind notwendig, um die TCOS-Smartcard und die De-Mail-Zertifikate zu integrieren:
Der die TCOS-Softwarekomponenten sind so programmiert, dass die De-Mail-Zertifikate beim ersten Zugriff auf die Signaturkarte in den lokalen Zertifikatsspeicher des angemeldeten Benutzers kopiert werden. Dieser Zertifikatsspeicher ist für installierte Softwarelösungen gänzlich ungeeignet. Die Zertifkate müssen in den Zertifikatsspeicher des Computers verschoben werden. Hierbei hilft Ihnen das Tool CertificatePromoter.exe, das Sie vom Net at Work-Support erhalten können.
Nachdem nun die De-Mail-Zertifikate im richtigen Zertifikatsspeicher abgelegt sind, muss der Zugriff auf die Zertifikate und die privaten Schlüssel konfiguriert werden. Die hierzu erforderlichen Schritte habe ich im Artikel "Zugriff auf privaten SSL-Schlüssel konfigurieren" beschrieben. Führen Sie die dort beschriebenen Schritte für die drei verschobenen De-Mail-Zertifikate durch.
Damit sind alle Voraussetzungen für eine funktionierende Anbindung des E-Mail-Security Gateways NoSpamProxy an De-Mail abgeschlossen. Die Konfiguration erfolgt in der NoSpamProxy MMC-Verwaltungsoberfläche im Menüpunkt Connected systems. Sie können entweder einen Telekom De-Mail-Connector oder einen Mentana-Claimsoft De-Mail-Connector hinzufügen.
Wenn alle Einstellungen und Konfiguration korrekt durchgeführt wurden, wird in der NoSpamProxy MMC-Verwaltungsoberfläche nach kurzer Zeit die Anzahl der zur Verfügung stehenden De-Mail-Domänen angezeigt. Diese Information wurde durch NoSpamProxy vom De-Mail-Gateway abgefragt und ist daher ein Beleg für die funktionierende Verbindung.
Ab diesem Punkt können Sie mit den weiteren Benutzer-Konfigurationen für De-Mail, entsprechend der NoSpamProxy Anleitung fortfahren.
Sollte es doch zu Problemen bei der Verbindung zum De-Mail-Gateway kommen, prüfen Sie bitte die folgenden Punkte:
Damit erschöpfen sich auch schon die allgemeinen Möglichkeiten zum Troubleshooting der De-Mail-Anbindung. In den meisten Fällen liegt ein Problem beim Verbindungsaufbau vor. Dies ist entweder die HTTPS-Strecke selbst oder aber die Aushandlung der TLS-Verschlüsselung (Handshake). Die Analyse des TLS-Handshake erfordert die Installation eines Werkzeuges zur Netzwerkanalyse, wie z.B. Wireshark oder Microsoft Message Analyzer.
# Prüfung der TLS-CipherSuite # Wird kein Ergebnis zurückgegeben, muss die CipherSuite aktiviert werden (Get-TlsCipherSuite) | Where-Object {$_.Name -eq 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384'} # Alphabetische Auflistung der konfigurierten TLS-CipherSuites des OS Get-TlsCipherSuite | Sort-Object Name | FT Name # Aktivierung der CipherSuite Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 # Auflistung der aktivierten elliptischen Kurven # Wird die Kurve NistP521 nicht aufgeführt, muss sie aktiviert werden Get-TlsEccCurve # Aktivierung der ECC Kurve NistP521 Enable-TlsEccCurve NistP521 # Alle Änderungen an den TLS-Einstelliunge erfordern einen Neustart des Servers
Ich wünsche viel Spaß mit dem NoSpamProxy E-Mail-Sicherheitsgateway und De-Mail.
Am 23. Oktober 2020 bin ich Gast beim WBSC#TALK mit Manfred Helber und Sven Langenfeld.
Wir unterhalten uns über das Supportende von Exchange Server 2010 und Office 2010 und die Frage, ob das Supportende dieser beiden Produkte zu einer Modernisierung der IT-Infrastruktur im deutschen Mittelstand führt. Ein weiteres Thema ist die Akzeptanz von Cloud-Angeboten wie Exchange Online und Microsoft 365.
Der WBSC#TALK findet als YouTube Live-Stream statt. Erstellen Sie schon jetzt eine YouTube-Erinnerung, um den Live-Stream nicht zu verpassen.
Das Blog Cumulative Update für Mai 2020 (CU0520) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Microsoft 365, Microsoft Teams und Azure des Monats Mai 2020 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Das Blog Cumulative Update für April 2020 (CU0420) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Microsoft Teams und Azure des Monats April 2020 zusammen.
Der virtualisierte Betrieb von Exchange Server ist seit der Einführung von Hypervisor-Plattformen immer wieder Thema für Diskussionen. Oftmals werden diese Diskussionen sehr emotional geführt und die richtigen Argumente für und gegen solch einen Betrieb finden selten Gehör. Das ist meist dann der Fall, wenn das Motto 100% Virtualisierung ausgerufen wurde.
Unabhängig von der Exchange Server Produktversion gibt es für die Planung und den Betrieb virtualisierter Exchange Server einen wichtigen Grundsatz:
Die Anforderungen an Prozessor, Arbeitsspeicher und Datendurchsatz der Festplatten für virtualisierte Exchange Server sind identisch zu den Anforderungen eines Betriebs auf physischen Servern.
Von diesem Grundsatz wird in der Realität immer wieder abgewichen. Abweichung von diesem Grundsatz haben aber automatisch Auswirkungen auf den stabilen und sicheren Betrieb von Exchange Server und erhöhen zusätzlich das Betriebsrisiko.
Mit Exchange Server 2019 haben sich empfohlenen Betriebsparameter für einen stabilen Betrieb, im Vergleich zu den Vorversionen, stark verändert.
Die empfohlene Prozessor-Konfiguration sieht weiterhin eine 2-Sockel-Architektur, allerdings mit insgesamt bis zu 48 Prozessorkernen (Cores) vor. Für den Betrieb eines Exchange Servers mit Postfach-Rolle ist eine Arbeitsspeichergröße von 128GB und für einen Server mit Edge Transport-Rolle eine Arbeitsspeichergröße von 64GB empfohlen.
Ob für Ihre Exchange Server 2019 Umgebung diese empfohlenen Betriebsparameter sinnvoll oder ob andere Betriebsparameter notwendig sind, finden Sie mit Hilfe des Exchange Server 2019 Sizing Calculator heraus. Der Calculator basiert auf einer Excel-Datei, die für Exchange Server 2019 ab dem Kumulativen Update 2 Bestandteil der Exchange Server 2019 ISO-Datei ist. Für Exchange Server 2016 können Sie die Excel-Datei direkt aus dem Microsoft Download Center herunterladen.
Die Virtualisierung von Exchange Server 2019 ist, wenn Sie sich nur an den Empfehlungen der Online Dokumentation orientieren, eine Herausforderung. Sie werden zu recht einwenden, dass niemand diesen Empfehlungen folgt, um Exchange Server 2019 produktiv zu betreiben. Meine Gegenfrage ist aber automatisch: Warum folgen Sie diesen Empfehlungen nicht? Die Empfehlungen basieren auf den jahrelangen Erfahrungen der Exchange Produktgruppe mit dem Betrieb von Exchange Server 2019 in großen und hochverfügbaren Umgebungen.
An dieser Stelle sei auch noch einmal darauf hingewiesen, was das Produkt Exchange Server ist:
Exchange Server ist eine Softwarelösung zur hochverfügbaren und sicheren Bereitstellung einer Massaging-Plattform für Clients und weitere Applikationen.
Vor dem Hintergrund der Empfehlungen für die Prozessor- und Arbeitsspeicherkonfiguration ist eine Virtualisierung von Exchange Server 2019 nicht immer sinnvoll. Wenn Sie eine Datenbankverfügbarkeitsgruppe (DAG) mit der Mindestanforderung von vier Mitgliedsservern konfigurieren, benötigen Sie auch mindestens vier Hypervisor-Host-Systeme. Der gleichzeitige produktive Betrieb von zwei Exchange Servern auf einem Host-System stellt ein beträchtliches Betriebsrisiko dar und ist im Regelbetrieb zu vermeiden.
Für den empfohlenen Betrieb des Exchange Server Gast-Systems müssen Sie in der Hypervisor-Plattform mit fest reservierten Ressourcen für Prozessor und Arbeitsspeicher arbeiten. Sie können bei der CPU-Ressourcenzuweisung zwar ein Verhältnis von 1:2 (pCore : vCore) konfigurieren, jedoch ist dies nur dann sinnvoll, wenn Sie sowohl die CPU-Auslastung des Gast-Systems, als auch des Host-Systems lückelos überwachen. Sobald auf dem Host-System weitere virtuelle Systeme betrieben werden, die eine hohe CPU-Last erzeugen, geht dies automatisch zu Lasten des Exchange Server-Systems.
Bedenken Sie bei der Konfiguration der Ressourcen immer, dass eine auf einem Windows Server betriebene Applikation immer genau die Ressourcen sieht, die das Betriebssystem meldet. Ist ein Server-System mit 24 vCores und 128GB Arbeitsspeicher konfiguriert, so nimmt die Applikation diese Ressourcen auch in Anspruch. Stehen diese Ressourcen bei einer dynamischen Zuweisung durch das Host-System nicht unmittelbar zur Verfügung, kommt es zu spürbaren Leistungsproblemen und zu Appkilationsfehlern.
Neben den Hypervisor-Herausforderungen für CPU-Cores und Arbeitsspeicher ergeben sich ebenso Herausforderungen für die Anbindung der notwendigen Speichermedien. Idealerweise verfügt das Gast-System für Exchange Server 2019 über nur ein, per Laufwerksbuchstaben eingebundenes Volume für das Betriebssystem und die Exchange Server Programmdateien. Alle weiteren Volumes zur Speicherung der Postfachdatenbanken und Protokolldateien werden über Mountpoints eingebunden. Je nach Anzahl der benötigten Volumes und der verwendeten Technologie zur Bereitstellung von Volumes in der Hypervisor-Plattform, stoßen Sie hier an Grenzen. Erschwert wird diese Situation noch dadurch, dass der hochverfügbare Betrieb einer DAG die Nutzung der AutoReseed-Funktion von Exchange Server vorsieht. Die AutoReseed-Funktion erfordert die Einbindung weiterer Volumes durch die Hypervisor-Plattform in das Gast-System.
Die Bereitstellung von leistungsstarkem Datenspeicher ist der neuralgische Punkt einer virtualisierten Exchange Server-Plattform. Für die Bereitstellung des erforderlichen Datenspeichers bieten Ihnen zahlreiche Hersteller die phantasievollsten Lösungen an. In den meisten Fällen handelt es sich um Lösungen, die eine Ersparnis des benötigten Gesamtvolumens für Exchange Server Postfachdatenbanken und Protokolldateien versprechen. Oftmals wird dies durch eine Form der Deduplizierung für die Postfachdatenbanken und Protkolldateien erreicht.
In solchen einem Fall muss Ihnen bewusst sein, dass Sie das Feld eines unterstützen Betriebes von Exchange Server 2019 verlassen. Sie nehmen Exchange Server eine der wichtigsten Funktionen für den Fall eines Desaster, die Datenbankportierbarkeit.
Jede weitere Technologieebene im Betrieb Ihrer Exchange Server-Plattform erhöht die Komplexität und die Zahl der möglichen Fehlerquellen. Hinzu kommt, dass Sie solch einen extern angebunden Datenspeicher immer redundant betreiben müssen, um das allgemeine Betriebsrisiko der Plattform zu minimieren. Bedenken Sie in diesem Zusammenhang auch, dass das Exchange Server Produktteam klassische HDD-Datenträger für die Speicherung von Datendateien empfiehlt, da SSD-Laufwerke nicht die notwendige Zuverlässigkeit und Robustheit aufweisen.
Mit Exchange Server 2019 wurde die Funktion der MetaCache-Datenbank (MCDB) eingeführt. Die Aufgabe der MCDB ist die Beschleunigung des Datenzugriffs auf häufig genutzte Postfachinformationen. Für den optionalen Betrieb einer DAG mit aktivierter MCDB-Funktion sind einige Voraussetzungen zu erfüllen:
Beim Betrieb einer Exchange Server Plattform mit physikalischen Servern verwenden Sie idealerweise passende M.2 SSD-Laufwerke, die direkt innerhalb des Servers verbaut sind. Auf diese Weise stehen Ihnen mehr Standardsteckplätze für die HDD-Laufwerke der Daten-Volumes zur Verfügung.
Aber wie können Sie von den Vorteilen der MCDB bei einem virtualisierten Betrieb von Exchange Server profitieren?
Wie bereits erwähnt, basiert die Nutzung der MCDB-Funktion auf SSD-Datenträgern. Bei einem Betrieb in einer Hypervisor-Plattform sind immer zusätzlichen Technologieebenen zwischen dem Betriebssystem und dem eigentlichen Datenspeicher, die den Geschwindigkeitsvorteilen einer direkten SSD-Anbindung in einem physikalischen Server entgegenstehen.
In einer Hypervisor-Plattform ist der Betrieb einer MCDB-Konfiguration nicht sinnvoll. Die zusätzlichen Laufwerke, insofern Sie als SSD-Laufwerke bereitgestellt werden können, erhöhen nochtmals die Komplexität der Plattform und erzeugen mit ihren Disk-I/O zusätzliche CPU-Last auf dem Host-System. Damit steigt das Risiko einer Verlangsamung des Datenzugriffs, sobald auf dem gleichen Host-System andere Applikationen mit hohen Systemanforderungen betrieben werden.
Daher ist meine Empfehlung, die MCDB-Funktion von Exchange Server 2019 nur beim Betrieb mit physikalischen Servern zu nutzen.
Der zu Exchange Server 2019 gehörende Role Requirements Calculator unterstützt Sie auch bei der Planung einer MCDB-Implementierung.
Wenn Sie einen virtualisierten Betrieb von Exchange Server 2019 planen, beachten Sie bitte immer die Empfehlungen der Exchange Server Produktgruppe in der Online Dokumentation. Diese Empfehlungen gründen auf den Erfahrungen im täglichen Betrieb von Exchange Server und den Exchange Server Supportfällen, basierend auf sehr individuellen Exchange Server Betriebsarten in Kundenumgebungen.
Achten Sie bei der Virtualisierung von Exchange Server 2019 auf eine möglichst einfache und standardisierte Implementierung. Jede zusätzliche Technologieebene erhöht nicht nur die Komplexität des Betriebs, sondern ist immer auch eine zusätzliche Fehlerdomäne. Vertrauen Sie nicht auf die Versprechen für vermeintlich leistungssteigernde Speicherlösungen für Ihre Exchange Server Systeme, die gerne von Systemhäusern als Allheilmittel angeboten werden.
Der Einsatz der MetaCache-Datenbank ist nur auf physikalischen Servern sinnvoll. Nur dort bietet die MCDB den gewünschten Geschwindigkeitsvorteil als Cache-Speicher zwischen Applikation und den Postfachdatenbanken.
Und vergessen Sie nicht, die Hochverfügbarkeit der Exchange Server 2019 erfolgt, wie bei allen modernen Exchange Server Versionen, auf Applikationsebene.
Und wenn Sie den Betrieb einer Einzelserverinstallation von Exchange Server 2019 planen, so möchte ich Ihnen den Wechsel zu Microsoft 365 und Exchange Online ans Herz legen.
Viel Spaß mit Exchange Server 2019.