Exchange SE Lizenzen

Lizenzsituation Exchange Server im Hybridbetrieb

Du planst 2 lokale Exchange-Server, die mit Exchange Online verbunden sind (Hybrid). Die Lizenzkosten hängen davon ab, ob es noch lokale Postfächer gibt und welche Microsoft 365 Lizenzen im Einsatz sind.

---

1. Alle Postfächer in der Cloud → kostenlose Hybridlizenz

• Wenn wirklich kein einziges Postfach On-Prem liegt, kannst du den kostenlosen Exchange Hybrid Server einsetzen.

• Keine Kosten für Serverlizenzen oder CALs.

• Lizenz wird über den Hybrid Configuration Wizard angefordert.

• Einschränkung: Die kostenlose Hybridlizenz darf nur für einen einzelnen Exchange-Server genutzt werden – kein zweiter Server für Hochverfügbarkeit oder Lastverteilung möglich.

---

2. Lokale Postfächer vorhanden, alle Benutzer mit Microsoft 365 E3/E5

• E3/E5 enthalten die Exchange-CAL-Rechte für On-Prem-Zugriff.

• Du brauchst nur die Serverlizenzen (Exchange SE Standard inkl. SA).

• 2 Server: aktuell ca. CHF 1’000 pro Jahr, ab Juli 2025 ca. CHF 1’100 pro Jahr (+10 % Preissteigerung).

---

3. Lokale Postfächer vorhanden, nicht alle Benutzer mit M365 E3/E5

• Für Benutzer ohne E3/E5 brauchst du zusätzlich CALs (ca. CHF 62 pro Benutzer/Jahr).

• Beispiel mit 5 lokalen Benutzern:

  • Serverlizenzen: CHF 1’000/Jahr

  • CALs: CHF 310/Jahr

  • Total: aktuell ca. CHF 1’310/Jahr, ab Juli 2025 ca. CHF 1’457/Jahr (wegen +10 % Serverpreis, +15 % CAL-Preis).

---

Fazit:

• Am günstigsten ist es, wenn alle Benutzer E3/E5 haben – dann fallen nur Serverkosten an.

• Wenn keine lokalen Postfächer vorhanden sind, kannst du komplett kostenlos mit der Hybridlizenz arbeiten, musst aber auf Hochverfügbarkeit verzichten.

• Sobald ein Postfach On-Prem liegt, reicht die Hybridlizenz nicht mehr aus.

Hyper-V Livemigration auf Windows Server Core schlägt fehl (0x8009030D)

 Die Installation eines Hyper-V Hostes mit Windows Server Core bietet sich an. Oder ihr verwendet eine der kostenlosen Windows Versionen "Hyper-V Server 2016" oder "Hyper-V Server 2019". Die kosten nichts, können aber nicht mit Desktop experience installiert werden.

Die Verwaltung der virtuellen Computer auf dem Hyper-V Host lässt sich wunderbar remote erledigen.

Doch vor kurzem habe ich doch etwas gefunden, was sich von der Ferne schlecht erledigen lässt. Wie ihr sicher wisst, funktionieren Livemigrationen von virtuellen Computern zwischen Hyper-V Hosts, auch wenn sie sich nicht als Cluster verbunden sind. Am einfachsten geht das zwischen Hyper-V Host welche Mitglied der gleichen Domäne sind.

Ich hatte damit nie Probleme, bis ich versucht habe eine VM per Livemigration von einem Hyper-V Host auf einen anderen Hyper-V Host zu verschieben und bei der Hyper-V Host's waren mit Windows Server Core installiert. Mir wurde eine unschöne Fehlermeldung angezeigt, die besagte, dass die Authentifizierung zwischen den Hyper-V Hosts nicht funktionierte und darum die VM nicht verschoben werden kann.

Dies ist die Fehlermeldung als Text:

Failed to establish a connection with host 'host name': No credentials are available in the security package (0x8009030E)

und in Deutsch:

Fehler beim Herstellen einer Verbindung mit dem Host 'host name': Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).

Das Problem ist, dass für die Authentifizierung zwischen den Hyper-V Hosts standardmässig CredSSP verwendet wird. Dies hat einen entscheidenden Nachteil: 

Man muss interaktiv an dem Hyper-V Host angemeldet sein, von dem aus man die Livemigration startet. Nur lässt sich auf einem Windows Server Core die Hyper-V Verwaltungskonsole nicht installieren. Man verwaltet die VMs aus der Ferne auf einem Admin-Server mit GUI.

Es gibt viele Vorschläge, wie man diese Problem lösen kann. Aus meiner Sicht ist es aber am einfachsten, die Livemigrationen direkt auf dem Hyper-V Host mit PowerShell zu starten:

Move-VM -Name Test-VM001 -DestinationHost Host01 -IncludeStorage -DestinationStoragePath "D:\Hyper-V\Test-VM001"

Sicherheitslücke in Exchange - Wurde ich schon angegriffen? Hafnium Test

 Es wurden ja in den letzten Monaten öfters Sicherheits-Updates für Exchange veröffentlicht. Doch die Sicherheitslücken, für welche Anfang März 2021 Patches veröffentlicht wurden, scheint eine der gefährlicheren zu sein. Informationen dazu gibt es auf dem Exchange Team Blog, im MS Security Blog oder auch bei EighTwOne.com.

Wichtig ist auch noch zu prüfen, ob schon ein Angriff stattgefunden hat, dies geht einfach mit dem Script  Test-ProxyLogon.ps1: https://github.com/microsoft/CSS-Exchange/tree/main/Security

Unter obigem Link gibt es noch weitere Scripts, welche zu diesem Thema gehören. Das Script ExchangeMitigations.ps1 soll nur angewendet werden, wenn ihr den Exchange Server aus irgendwelchen Gründen nicht sofort Patchen könnt. Das selbe gilt für BackendCookieMitigation.ps1. Diese beiden Scripts benötigt ihr also nicht, wenn ihr die Sicherheits-Updates installiert.

Das Script CompareExchangeHashes.ps1 nutzt euch nur etwas, wenn ihr einen Supportvertrag mit Microsoft habt. Es soll zusätzlich prüfen, ob ihr angegriffen worden seid. Das Problem ist aber, dass das Script 600 - 800 MB grosse XML-Dateien produziert und immer sagt, ihr seid angegriffen worden. Auch wenn man das Script auf einem neu installierten Exchange Server ohne Internetverbindung ausführt, wie ihr hier nachlesen könnt: https://www.reddit.com/r/sysadmin/comments/m16y8m/hafnium_breach_recap_new_compareexchangehashes/
Am Ende könnt ihr dass eben die XML-Dateien bei Microsoft hochladen, doch eben nur mit einem Supportvertrag.

Jedoch gibt es noch das Script HealtjCheck, welches sehr hilfreich ist: https://github.com/dpaulson45/HealthChecker#download

Damit könnt ihr einfach nachschauen, ob alle eure Exchange Server aktuell sind und es werden sonst noch sinnvolle Einstellungen geprüft.

Wenn euere Exchange Organisation aus mehren Exchange Server besteht, startend ihr das Health Checker Script am einfachsten mit folgenden Command:

Get-ExchangeServer | ?{$_.AdminDisplayVersion -Match "^Version 15"} | %{.\HealthChecker.ps1 -Server $_.Name}; .\HealthChecker.ps1 -BuildHtmlServersReport; .\ExchangeAllServersReport.html

Schon wieder ein neuer Sicherheits-Patch für Exchange (CVE-2020-16969)

 Kaum haben wir unsere Exchange-Umgebungen wieder sicher gemacht, indem eines der neusten CU's installiert wurde, erscheint schon wieder ein neuer Sicherheits-Patch für Exchange. Folgende Versionen sind betroffen:

• Microsoft Exchange Server 2013 Cumulative Update 23
• Microsoft Exchange Server 2016 Cumulative Update 17
• Microsoft Exchange Server 2016 Cumulative Update 18
• Microsoft Exchange Server 2019 Cumulative Update 6
• Microsoft Exchange Server 2019 Cumulative Update 7

Das Problem hat damit zu tun, wie Exchange Token validiert. Ein Angreifer, der die Sicherheitslücke erfolgreich ausnutzt, kann dies verwenden um weitere Informationen von einem Benutzer zu erhalten.

Hier die Original-Beschreibung von Microsoft:

An information disclosure vulnerability exists in how Microsoft Exchange validates tokens when handling certain messages. An attacker who successfully exploited the vulnerability could use this to gain further information from a user.

To exploit the vulnerability, an attacker could include specially crafted OWA messages that could be loaded, without warning or filtering, from the attacker-controlled URL. This callback vector provides an information disclosure tactic used in web beacons and other types of tracking systems.

The security update corrects the way that Exchange handles these token validations.

Quelle: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-16969

Unter dem Link findet ihr weitere Informationen und könnt die Sicherheits-Paches herunterladen.

Der Patch kommt als *.msp und ist in etwa 160 MB gross. Während der Installation werden die Exchange Services sowie der IIS gestoppt. Es gibt also einen Dienstunterbruch um am Ende muss der Server neu gestartet werden. Bei mir hat die Installation ca. eine Stunde gedauert. Am Ende musste der Server neu gestartet werden.

Startet die Installation in einem CMD mit erhöhten Rechten und falls ihr eine Umgebung mit mehreren Exchange Servern betreibt, setzt die Server vor der Installation in den Maintenance Mode.

Exchange Sicherheits-Updates

 Gerade geht wieder durch die Fachpresse, dass es immer noch diverse Exchange Umgebungen gibt, welche dringend Sicherheitsupdates benötigen. Erstaunlich ist vor allen, dass die aktuellen Meldungen eine bekannte Sicherheitslücke betreffen, welche seit Anfang 2020 bekannt ist, seit Februar 2020 gibt es einen Patch dafür (CVE-2020-0688). Aktive Angriffe sind bekannt.

Im Sommer 2020 wurde eine weitere Sicherheitslücke bekannt. Dafür hat Microsoft im September 2020 einen Patch veröffentlicht (CVE-2020-16875).

Beide Sicherheitslücken schliesst ihr am einfachsten, indem ihr die neuesten CU's installiert.

Exchange 2019 CU7

Exchange Server 2016 CU18

Exchange Server 2013 CU23

Sicherheitslücken gibt es immer wieder. Gefährlich wird es, wenn die Lücken bekannt werden und die ersten aktiven Angriffe verzeichnet werden. Ab dann, werdet ihr nicht mehr von Hackern, sondern von Scriptkiddie angegriffen!

Nachlesen lässt sich das z.B. bei Heise: https://www.heise.de/news/Dringend-patchen-Rund-eine-viertel-Million-Exchange-Server-angreifbar-4920095.html

Virtual geekmania Extended Edition

Das in diesem Jahr alles etwas anders ist ist leider eine Tatsache. Auch unser Fachkongress, die Geekmania ist davon betroffen. Sie findet diese Jahr virtuell online statt.

Weiter Informationen findet ihr hier: https://geekmania.ch/vgm/vgmee/

Im übrigen haben wir durch das momentane virtuelle Format diverse neue lehrreiche Videos auf unserem YouTube Kanal: iTrain GmbH YouTube Kanal

Neue Exchange Version angekündigt (Exchange vNext)

 Seit einigen Jahren steht betreffend MS Exchange immer wieder die gleiche Frage im Raum: Wird Microsoft noch eine neue Exchange Version on-premise herausbringen?

Nun, vor ein paar Tagen hat Microsoft an der Ignite verkündet, dass es in der zweiten Jahreshälfte 2021 die nächste Exchange Version für lokale Installationen geben wird.

Das ist doch nett, denken sich die meisten ;-) Schauen wir uns doch erst mal an, was Microsoft denn angekündigt hat:

• Migration von Exchange 2019 auf "Exchange vNext" ist als Inplace Upgrade möglich. Das heisst, Exchange vNext lässt sich auf einem Exchange 2019 genauso wie ein CU installieren. Man muss nicht parallel neue Server aufbauen und alles rüber migrieren.
  
  
• Exchange vNetxt erlaubt eine Koexistenz mit Exchange 2013, 2016 und 2019. Bis anhin waren immer nur die 2 letzten Versionen unterstützt. Nun sind es also die 3 letzten Versionen.
  
  
• Exchange vNext Lizenz gibt es nur subscription-based, also als Abo.

Wenn man sich diese Punkte auf der Zuge zergehen lässt und ein paar wenige graue Zellen im Hirn hat, dürfte jedem klar sein, was Microsoft mit dieser Exchange vNext Version für Ziele hat ;-)

Soviel , zu "nette Microsoft", wir dürfen ein CU bei euch kaufen und das geht nur im Abo ...

Exchange Team Blog zum Thema

geekmania 2019: Keynote: Microsoft, wir müssen reden!

geekmania 2019: Die Fischer von gestern sind die IT-Terroristen von Morg...

geekmania 2019: Hyperconverged! Die Mitmachsession - Part I

geekmania 2019: Exchange Troubleshooting

Page File auf einem Windows Server 2019 CORE anpassen

Wir betreiben einen Hyper-Converged Cluster mit 2 Nodes unter Windows Server 2019 CORE. Jeder Node verfügt über 192 GB RAM. Da unsere OS Laufwerke aber eine Grösse von 220 GB haben, wurde der freie Speicherplatz auf dem OS Laufwerk knapp, denn die Page Files haben eine Grösse von 192 GB.

Daher habe ich die maximale Page File Grösse angepasst, was gar nicht so einfach ist. Es gibt ja keine Grafische Oberfläche, um die Konfiguration des Page Files anzupassen. Doch wenn man mal herausgefunden hat, wie es gemacht werden muss, ist es gar nicht mehr so schwer.

Zuerst einmal schauen wir uns die momentane Konfiguration an:

wmic.exe pagefileset

Geekmania 2018 - Meine Exchange 2019 Session ist online

Letzten Freitag war die Geekmania 2018. Meine Session über Exchange 2019 könnt ihr euch online ansehen:
About Exchange 2019 - Geekmania 2018

Alle Sessions an der Geekmania der iTrain Mitarbeiter findet ihr hier:
Alle iTrain Sessions - Geekmania 2018

Viel Spass damit!

Externer OAB Download benötigt 30 Minuten

Ich hatte gerade bei einem Kunden den Fall, dass der manuelle Download des OAB in Outlook nach einer Migration auf Exchange 2016 30 Minuten benötigte. Nachdem wir den Download des OAB in Outlook manuell gestartet haben, blieb das Fenster, welches den Vorschritt des Downloads anzeigt, einfach ohne Reaktion stehen:

Irgendwann haben wir dann auch genug lange gewartet und bemerkt, dass der Download nach 30 Minuten startet und auch erfolgreich ist.

Nach längerer Suche haben wir dann das Problem gefunden. Der Download des OAB läuft über BITS. BITS hat einen Standard-Timeout von 30 Minuten, wenn eine URL nicht erreichbar ist. Dies passt ja genau zur Wartezeit beim Download des OAB...

Im Eventlog "Bits-Client" (Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> Bits-Client) habe ich dann den Event mit der ID 61 (Quelle: Bits-Client) gefunden und gesehen, dass Outlook versucht das OAB auf der internen URL herunterzuladen. Erst nach 30 Minuten wird die "alternative" URL kontaktiert.

Wir haben das virtuelle Verzeichnis für OAB mit einer internen URL (FQDN/oab) und einer externen URL (mail.mydomain.ch/oab) konfiguriert. Nun scheint es so zu sein, dass Outlook nicht wirklich weiss, ob es intern oder extern ist und verwendet für das OAB zuerst die interne URL, welche aber von Extern nicht erreichbar ist.

Die Lösung in meinem Fall: Auf dem virtuellen Verzeichnis für OAB für interne und externe URL die externe URL eintagen. So kommt Outlook gar nicht erst in Versuchung, die interne URL zu probieren.

Der Grund für das Problem kann nur ein Bug sein.

Exchange Log Partition läuft voll

Grundsätzlich sollte dies nicht passieren. In einer produktiven sorgt das Backup dafür, dass die Logfiles der Datenbanken nach jedem erfolgreichen Backup gelöscht werden. Dies verhindert, dass die Log-Platten eines Exchange Servers voll laufen.

In einer Testumgebung wird eher selten ein funktionierendes Backup eingerichtet. Daher kann es vorkommen, dass die Laufwerke mit den Logfiles der DBs gefüllt werden. Um die Logs wieder los zu werden, gibt es einen simplen Trick.

1. Starte auf dem Exchange ein CMD mit erhöhten Rechten
   
2. Tippe "Diskshadow" und drücke Enter
   
3. Tippe "add volume x:" und drücke Enter (das "x" mit dem Laufwerksbuchstaben ersetzen, auf welchem die Logs liegen)
   
4. Tippe "begin Backup" und drücke Enter
   
5. Tippe "create" und drücke Enter
   
6. Wenn der Vorgang abgeschlossen ist, tippe "end Backup" und drücke Enter

Nach kurzer Zeit kann man zusehen, wie sich die Logfiles "in Luft auflösen".

Die Verwendung dieser Prozedur geschieht auf eigene Gefahr ;-)