Exchange 2016 - Erste News von der Ignite 2015

Die ersten Infos über Exchange vNext sind nun draussen. die ersten Sessions zum Thema an der Ignite 2015 sind gelaufen. Hier ein paar Facts:

Release Date

• Exchange 2016 Public beta ist auf Sommer 2015 angesagt. RTM soll im Herbst / Winter 2015 verfügbar sein.

Architektur

• Keine Trennung der Rollen bei der Installation. Also keine reinen CAS oder MBX Server mehr
• CAS Proxing zwischen Exchange 2016 und 2013 möglich, und dies in beide Richtungen
• Gemischte Umgebungen mit Exchange 2010 SP3 RU11 (oder höher) oder Exchange 2013 CU10 (oder höher)
• Wie zu erwarten war, keine Koexistenz mit Exchange 2007
• Als OS wird 2012 R2 und Server 10 unterstützt
• Forest und Domain Level müssen 2008 R2 oder höher sein
• Es werden Outlook 2010 SP2 (mit KB2956191 und KB2965295 oder höher), Outlook 2013 SP1 (mit KB3020812 oder höher) und Outlook 2016 unterstützt
• Als Standard-Clientprotokoll wird MAPI/HTTP verwendet
• Witness Share (Zeugenserver) in Azure möglich

Speicherung der Daten

• 22% weniger IOPS im Vergleich zu Exchange 2013 RTM (und täglich grüsst das Murmeltier)
• Der Suchindex wird auf der passiven Kopie einer Datenbank erstellt

Hochverfügbarkeit

• DAG hat kein Clusterobjekt (CNO) mehr
• Schnellere Datenbank-Umschaltung
• Weitgehend die gleichen Anforderungen an Load Balancer wie bei Exchange 2013

Weitere News werde ich wieder Posten.

ADFS 3.0 non SNI Client Support konfiguration

Seit Windows Server 2012 R2 ist ADFS in der Version 3.0 verfügbar. Eine der grossen Änderungen ist, dass das es ADFS Proxy nicht mehr gibt. Es wird auch keine IIS mehr benötigt. Dafür ist aber der Support von SNI dazu gekommen. Aber was ist denn SNI überhaupt? SNI heisst «Server Name Indication». Infos über SNI gibt es hier und hier.

Wie ihr also in den Links oben lesen könnt, sind «nur» neuere Clients in der Lage SNI-Informationen im TLS Handshake mitzusenden. Die Clients machen mir aber in der Praxis nur selten Sorgen. Es ist eher so, dass ADFS Umgebungen meist redundant aufgebaut werden und daher auch ein Load Balancing benötigen. Nun ist es eben so, dass die meisten Load Balancer nicht mit SNI umgehen können oder diese Informationen auf dem Backend einfach nicht weiter geben.

Ein ADFS 3.0 Server möchte aber in der Default-Konfiguration diese Information haben. Anfragen ohne SNI Informationen werden nicht verarbeitet. Also müssen wir den ADFS 3.0 Server dazu bringen, diese Anfragen trotzdem zu verarbeitet. Bewerkstelligt wird dies, indem man ein Standard Zertifikat definiert. Und gemacht wird dies so: