Stichwort Suche

Monat: Oktober 2018

Willkommen Exchange 2019 – installiert – migriert – getestet

Da ist er, der Exchange 2019. Ich habe ihn mal in meiner Umgebung Zuhause installiert und getestet 🙂

 

Vorraussetzungen:

Exchange 2019, was brauchs zum laufen? Kurzfassung, wer die letzten Jahre fleißig geupdate hat, hat kaum Probleme, alle Exchange 2010 Betreiber müssen ein bisschen was nachholen.

 

  • Betriebssystem

Man beachte die Hinweise/Empfehlungen 🙂

  • Active Directory

  • Exchange Coexistenz

  • Clients

Installation:

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

  • Active Directory: Schema und Domänen vorbereiten

 

Da Windows Server 2019 zum aktuellen Zeitpunkt nicht mehr zum Download bereit stand, habe ich probiertExchange 2019 einfach mal auf Windows Server 2016 zu installieren.
Jedoch weigerte sich das Setup dagegen..

Zum Glück konnte ich einen Kollegen finden, der Server 2019 vor dem rückzieher von Microsoft schon heruntergeladen hatte 🙂

Also erstmal noch fix eine Windows Server 2019 VM erstellt – es hat sich zu Server 2016 nicht wirklich viel verändert – nur booten tut Server 2019 extrem schnell!

 

Danach weiter mit dem Exchange 2019 Setup:

Die weiteren Steps unterscheiden sich nicht zu den vorherigen Versionen.

 

 

Ich habe auf meinem Exchange 2013 vorher Organisationsweit “MapiHttp” deaktiviert um einmal zu schauen, was bei dem Setup von Exchange 2019 passiert. Anderst als Exchange 2013 und Exchange 2016 unterstüzt Exchange 2019 keine Outlook Anywhere (RPC/HTTP), sondern nur noch MAPI/HTTP.

Und siehe da, das Setup prüft dies ab und gibt. ggf. eine Warnung aus. Also vorher noch aktivieren 😉

 

Test:

  • Anpassungen Exchange 2019

Die Anpassungen der virtuellen Verzeichnisse etc. hat ohne Probleme funktioniert. Lediglich der Exchange Server hat etwas Performance Probleme gehabt. Ich habe die VM in meiner Demo Umgebung mit 2vCPU und 6GB am laufen gehabt. Das reicht dem Exchange 2013 ohne Probleme aus. Dem Server 2019 mit Exchange 2019 ist dies auf jedenfall zu wenig, also habe ich mal auf 8GB RAM erhöht mal schauen, ob das für eine minimal Umgebung reicht 😉

  • Zugriffe

Zuerst habe ich einmal die Anbindung von intern und extern  (reverse proxy Sophos UTM) von dem Exchange 2013 auf den Exchange 2019 angepasst.

Die Zugriffe von intern und extern mit Outlook und einem iOS Gerät auf das Postfach auf dem Exchange 2013 haben ohne Probleme funktioniert.

  • Postfach Move Nummer 1

Der erste Postfach Move war etwas holprig. Mein Postfach hat sich bis 95% Problemlos gesynct, stand danach jedoch auf einem Fehler.

 

 

Es war jedoch nichts schlimmes ersichtlich:

 

 

 

Scheinbar wurde der Job wirklich wegen dem Fehler nicht ausgeführt:

 

Ich musste den Move dann manuell abschließen:

 

 

  • Postfach Move Nummer 2

Den gleichen Fehler wie bei Move Nummer 1.

 Email migration failed for this user because the subscription was suspended externally to the Migration Service

Sehr komisch.

 

  • Postfach auf Exchange 2019

Die ersten Tests haben soweit alle funktioniert. Alles weitere wird sich die nächsten Tage zeigen 🙂

Was auf jedenfall schon einmal positiv auffällt ist die verbesserte Suchfunktion – die Suche ist wirklich richtig schnell und genau.

Falls sich etwas negatives ergibt, werde ich ein kurzes Update posten.

 

 

WAP to ADFS with Kemp Loadbalancer no connection – TCP syn checking failed

Eine Verbindung von einem WAP Server (DMZ) zu einem ADFS Server ist nicht möglich. Der WAP und der ADFS Server befindeen sich hinter einem Two-Arm Kemp Loadbalancer.

Die direkte Verbindung von dem WAP zu dem ADFS ohne Kemp Loadbalancer dazwischen funktioniert.

Im Firewall Log der Watchguard zwischen DMZ und LAN ist folgende Meldung sichtbar.

“TCP syn checking failed (expecting SYN packt for new TCP connection, but received ACK, FIN, or RST instead).

Der TCP Flag der Watchguard ist Fehlerhaft, daher dropt die Watchguard das Packet zu dem Kemp.

Die Lösung mithilfe des Kemp-Support ist folgende:

In dein Einstellungen die Option: Use Default Route Only setzen

 

 

Find Active Directory Schema Update History

$schema = Get-ADObject -SearchBase ((Get-ADRootDSE).schemaNamingContext) `
-SearchScope OneLevel -Filter * -Property objectClass, name, whenChanged,`
whenCreated | Select-Object objectClass, name, whenCreated, whenChanged, `
@{name=”event”;expression={($_.whenCreated).Date.ToShortDateString()}} | `
Sort-Object whenCreated

$schema | Format-Table objectClass, name, whenCreated, whenChanged `
-GroupBy event -AutoSize

$schema | Group-Object event | Format-Table Count, Name, Group –AutoSize