Quarterly Updates Q3 für Exchange 2016 und 2013 erschienen

[Nobbyaushb 1.359]

​Hallo zusammen,

​

soeben wurden die Quarterly Updates vom Exchange Team veröffentlich.

​

Den ganzen Blog wie immer in en findet ihr hier:

https://blogs.technet.microsoft.com/exchange/2016/09/20/released-september-2016-quarterly-exchange-updates/

 

Neu ist der Support für Server 2016 mit Exchange 2016 CU3

 

2013 ist weiterhin nicht auf Server 2016 supportet, meiner Meinung nach bleibt das auch so.

 

Viel Spaß bei patchen!

 

Norbert

[substyle 20]

Danke! Dann steht unserer Migration ja nicht mehr viel im Weg. Sauber ..

[NorbertFe 1.804]

Nicht nur deiner Meinung nach. ;)

Exchange Server 2013 will not be supported on Windows Server 2016.

 

Kann man übrigens auch schön sehen. Jede Exchange Version der letzten Jahre war auf 3 Server os supported. Einzige Ausnahme war Exchange 2007 sp3, die dann noch 2008r2 spendiert bekam. ;)

[Nobbyaushb 1.359]

;)

bearbeitet 21. September 2016 von Nobbyaushb

[PowerShellAdmin 169]

Danke - hatte gestern noch bei den Zwickereien geschaut, ob bereits das September CU bereitgestellt war ;)

Was mir auffällt, dass die Updates mit Exchange 2016 deutlich mehr Zeit als auf dem Exchange 2010 benötigen.

Ist das mittlerweile generell so oder nur beim CU3 ?

[NorbertFe 1.804]

Das sind cus, die im allgemeinen länger dauern als die rollups von 2010.

[Nobbyaushb 1.359]

CU´s sind ja seit Exchange 2013 im Prinzip eine Neuinstallation mit Anpassung der Datenbank(en)

 

;)

[NorbertFe 1.804]

Naja entspricht also eigentlich den servicepacks vorheriger Versionen.

[PowerShellAdmin 169]

Dann bin ich froh, dass ich bin uns nen kleines DAG bereitstellen werde.

Dass die CUs länger brauchen habe ich mir gedacht, allerdings schon ein ordentliches Stückel länger als das SP3 beim Ex2010 ;)

[NorbertFe 1.804]

Naja ich hab zwischen 20-90 Minuten bei Exchange 2013 erlebt. Muss also nicht zwingend ewig dauern. ;)

[PowerShellAdmin 169]

Bei uns ist "noch" Exchange 2010 im Einsatz, hier waren die Installationszeiträume andere, auch das Servicepack 3 ging zackig.

Bei Exchange 2013 ist das mit Sicherheit anders, da hier natürlich doch ein sehr großer Bruch im Vergleich zu Ex 2010 ist.

 

Aber mir gefällt der 2016er wirklich gut. Gerade da wir über die Lizenzen verfügen und bei uns Mailing eine wichtige Priorität hat, liegt eine Umsetzung einer DAG recht nahe.

2 Nodes auf getrennten Blechen, Postfächer werden auf 2 DBs verteilt - kreuz gespiegelt.

Jeder Node hängt an einem separaten Internetanschluss, CAS Zugriff intern und extern via Round Robin, MX entsprechend 2 Records und SMTP ...

Natürlich kein richtiges HA und auch kein intelligenter Lastenausgleich, aber funktional mit einer deutlich erhöhte Verfügbarkeit und obendrauf auch noch eine Spiegelung der Daten.

bearbeitet 21. September 2016 von PowerShellAdmin

[testperson 1.534]

DNS Round Robin Überleg dir das lieber noch zwei, drei mal.

bearbeitet 21. September 2016 von testperson

[Nobbyaushb 1.359]

DNS Round Robin Überleg dir das lieber noch zwei, drei mal.

Genau - leiber einen kostenlosen Kemp (oder zwei) davor, oder ein bisschen Geld in die Hand nehmen.

 

2016 kann man super virtualisiern.

 

;)

[PowerShellAdmin 169]

DNS Round Robin betrifft hier lediglich den Client Access - Also autodiscover, EAS, Outlook Anywhere und OWA.

 

-Zufallsprinzip des CAS Systems => keine intelligente Lastenverteilung

-Nach Ausfall Verzögerung von etwa 20 Sekunden

 

So wie ich es rausgelesen habe, durchaus eine gangbare Alternative, soweit man keinen LB benötigt => wir haben nur eine kleine Umgebung.

Bin derzeit am Testaufbau und werde mir dann ein eigenes Bild von machen.

 

Edit: Werde mir mal Kemp anschauen ;) Danke für den Tipp.

bearbeitet 21. September 2016 von PowerShellAdmin

[MrCocktail 188]

Hi,

 

auch wenn ich LB bevorzuge, kann man für den CAS Zugriff bei Exchange 2016 tatsächlich den DNS RR gebrauchen... Hatten wir bei einem Kunden mit 200 Mailboxen im Einsatz, bis die beiden LBs geliefert wurden.

 

Einschränkungen für den normalen Betrieb keine, Fehlerfall (provoziert) war wirklich innerhalb von 30sek. max. abgefangen...

 

Gruß

J