Aktualisierung DCs 2012 R2 auf 2019 / 2022

[Robinho1986 1]

Gerne würde ich eine Domäne mit 2x Server 2012 R2 auf Server 2019 / 2022 aktualisieren.

 

Die Schritte die eine Migration erfordern sind mir bekannt. Allerdings befindet sich in der aktuellen Domäne noch ein Exchange Server 2016 und ich versuch aktuell zu ergründen, welche Hürden da auf mich zukommen werden, gerade in Hinblick auf heraufstufen der Funktionsebenen und Co.

 

Habe schon gesehen, dass Server 2022 mit on prem Exchange 2016 nicht supported wird!

Exchange Server supportability matrix | Microsoft Docs

 

Würde von daher erstmal auf Server 2019 gehen. Gibt es denn Dinge, die ich bei der Migration der Domäne in Hinblick auf Exchange 2016 beachten muss?!

Das Ganze werde ich natürlich vorab in einer Lab-Umgebung durchspielen mit exportierten produktiv Servern.

 

Vielen Dank vorab!

[NorbertFe 2.027]

vor 19 Minuten schrieb Robinho1986:

Exchange Server 2016

Dann darfst du maximal Domain Controller mit Windows Server 2019 einsetzen. Das Domain/Forest Functional Level ist bei CU 22/23 auf jeden Fall Windows Server 2016 (mehr gibts ja nicht) ;) Beachten muss man da nix.

[lukas2002 1]

vor 9 Stunden schrieb NorbertFe:

Dann darfst du maximal Domain Controller mit Windows Server 2019 einsetzen. Das Domain/Forest Functional Level ist bei CU 22/23 auf jeden Fall Windows Server 2016 (mehr gibts ja nicht) ;) Beachten muss man da nix.

Aber Windows Server 2022 hat auch kein anderes Domain/Forest Functional Level als Windows Server 2019.
Windows Server 2022 wäre aber aus meiner Ansicht noch zu früh, es könnten noch zu viele Bugs auftreten und wenn du das produktiv nutzen willst, ist das die Frage, ob das so sinnvoll ist?

 

Gruß Lukas

[tesso 375]

Schau dir die Supportmatrix von Exchange an. 
Es ist nicht supportet. 

[cj_berlin 1.306]

vor 21 Minuten schrieb lukas2002:

Windows Server 2022 wäre aber aus meiner Ansicht noch zu früh, es könnten noch zu viele Bugs auftreten und wenn du das produktiv nutzen willst, ist das die Frage, ob das so sinnvoll ist?

Die Bugs kommen monatlich am Patchday rein, kann also auch 2012R2 noch betreffen. So geschehen beispielsweise auch diesen Winter  

[NorbertFe 2.027]

vor 58 Minuten schrieb lukas2002:

Windows Server 2022 wäre aber aus meiner Ansicht noch zu früh, es könnten noch zu viele Bugs auftreten und wenn du das produktiv nutzen willst, ist das die Frage, ob das so sinnvoll ist?

 

Wie schon geschrieben. Das ist aber neulich auch mit Windows 2012R2 passiert. ;) Also ob das (deine Ansicht) sinnvoll ist?

vor 59 Minuten schrieb lukas2002:

Aber Windows Server 2022 hat auch kein anderes Domain/Forest Functional Level als Windows Server 2019.

Hab ich das behauptet? Trotzdem ist Exchange 2016 (CU23) nur bis Windows Server 2019 Domain Controller supported.

[lukas2002 1]

vor 51 Minuten schrieb cj_berlin:

Die Bugs kommen monatlich am Patchday rein, kann also auch 2012R2 noch betreffen. So geschehen beispielsweise auch diesen Winter  

Aber was ich persönlich bisher mitbekommen habe, ist das seltener aufgetreten. 

 

vor 14 Minuten schrieb NorbertFe:

Hab ich das behauptet? Trotzdem ist Exchange 2016 (CU23) nur bis Windows Server 2019 Domain Controller supported.

Jo, bin leider in der Spalte verrutscht :(

bearbeitet 5. Mai 2022 von lukas2002

[daabm 1.348]

vor 2 Stunden schrieb lukas2002:

Aber was ich persönlich bisher mitbekommen habe, ist das seltener aufgetreten. 

 

Nope. Da war ne Menge dabei, die uns extrem Ärger verursacht hat. Februar war am besten Netlogon kaputt bei Trusts (Name Suffix Routing plötzlich weg - und wir haben Trusts im 4-stelligen Bereich), NTLM-Logon mit längeren Kennwörtern kaputt, wir sind grad nur noch am Ko**en....

Und das zog sich jeweils quer über die OS-Versionen.

[Robinho1986 1]

Danke für die Rückmeldungen! Eine Frage habe ich noch.

 

Aktuell laufen 2x DCs 2012 R2. Macht es Sinn den zweiten, welcher NICHT die FSMO Rollen beherbergt, vorher komplett aus der Domäne zu entfernen und dann den einzelnen zu migrieren. Anschließend würde ich dann wieder einen zweiten redundanten DC aufsetzen. 

bearbeitet 17. Mai 2022 von Robinho1986

[NilsK 2.930]

Moin,

 

nein, das ergibt keinen Sinn. Der regelmäßig empfohlene Weg, eine Domäne zu aktualisieren, besteht darin, neue DCs mit dem neuen Betriebssystem zu installieren, statt vorhandene mit einem Upgrade zu bearbeiten. Die alten DCs deinstalliert man danach.

 

Gruß, Nils

 

[Robinho1986 1]

Ich glaube ich habe mich etwas falsch ausgedrückt. Ich versuche es nochmal.

 

Aktuell laufen 2x DCs 2012 R2. In der Theorie könnte ich vor der Migration einen davon bereits komplett aus der Domäne entfernen, sodass nur noch ein Server 2012 R2 läuft. Dann würde ich einen neuen Server 2019 installieren in die Domäne aufnehmen und die Rollen verschieben. Sobald der neue Server 2019 läuft, würde ich dann einen weiteren 2019er aufsetzen. 

 

Ein In-Place Upgrade würde ich nicht durchführen. 

bearbeitet 17. Mai 2022 von Robinho1986

[cj_berlin 1.306]

Genau so macht man das. Denk daran, ihn auch aus Sites & Services zu entfernen und so lange zu warten, bis der KCC alle Replikationsverbindungen von alleine entfernt hat.

[NilsK 2.930]

Moin,

 

nein, das ist nicht sinnvoll. Damit verzichtest du zeitweise auf Redundanz und erhöhst das Risiko, ohne dass du einen Nutzen davon hast.

 

Vereinfacht:

1. vorhanden sind 2 DCs mit OS-alt
2. dazu installierst du einen neuen Server mit OS-neu und stufst ihn zum DC hoch
3. du verschiebst die FSMO-Rollen auf den neuen DC
4. du installierst einen oder mehrere weitere neue DCs mit OS-neu
5. du deinstallierst die DCs mit OS-alt
6. du stufst den Domänen- und Forest-Modus hoch

Schritte 4 und 5 kannst du auch "mischen" bzw. parallel machen. Es gibt aber keinen Gund und erst recht keinen Vorteil, an irgendeiner Stelle auf DC-Redundanz zu verzichten.

 

Gruß, Nils

 

bearbeitet 17. Mai 2022 von NilsK

[cj_berlin 1.306]

vor einer Stunde schrieb NilsK:

nein, das ist nicht sinnvoll.

Doch, ist es. Auf diese Weise behältst Du IP-Adressen und Namen der DCs, ohne fertig hochgestufte DCs nachträglich verändern zu müssen. 99% meiner Kunden wissen nicht mit absoluter Sicherheit, wo welche Maschinen für DNS und LDAP mit Namen oder sogar IP-Adressen eingetragen sind. Doch selbst wenn man es wüßte - will man jede doofe Appliance, jeden Drucker usw. usw. anfassen und IP-Adressen ändern?

 

Man kann natürlich, wenn man nur zwei DCs hat, zuerst einen dritten installieren und ihn zum Schluss wieder entfernen. Aber bereits wenn man drei DCs hat, verzichtet man auch bei reiner Rotation zu keinem Zeitpunkt auf Redundanz. Aber auch bei zwei DCs dauert der Verlust der Redundanz bei ordentlicher Vorbereitung 18 Minuten, 15 davon braucht der KCC, um die Replication Links neu auszuwürfeln.

[testperson 1.674]

vor 44 Minuten schrieb cj_berlin:

Doch selbst wenn man es wüßte - will man jede doofe Appliance, jeden Drucker usw. usw. anfassen und IP-Adressen ändern?

 

Muss man doch gar nicht wissen. Ich zitiere einmal aus Load balancers and Active Directory - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com):

Zitat

Well the fairest solution is to walk to the vendor and ask them to change their design. You need to inform them that their product is not knowledgeable enough to understand AD and this will decrease the utilization of their product when there are AD involved. 

 

Welcher Hersteller möchte schon mit der Schmach leben, dass seine Anwendung, das Active Directory nicht versteht.