Migration von DC 2k3 auf 2k16 möglich?

[lefg 276]

Nun, dann installiere doch den 2016 in einer VM, promote ihn zum weiteren DC der Domäne, verschiebe die Rollen darauf. Falls gewollt kann der 2003 runtergestuft werden, er stört doch aber nicht, kann doch noch bleiben.

 

Zum Testen der Domäne und der Namenauflösung kann man den 2003 dann mal vom Netz trenne, herunterfahren oder einfach den Netzwerkstecker ziehen. Dann mal Testen ob es mit dem 2016 funktioniert, -auch nach einem Neustart- z.B. das Anmelden der Benutzer mit den Clients.

 

Den 2003 sichern? Der wird ja nicht angefasst, also eigentlich keine Sicherung nötig, Aber falls man sich besser fühlt, vorsicht ist die Mutter der Porzelankiste.

 

Wozu ist eigentlich das Bind9 da? Soll das bleiben? Normalerweise in einer AD-Domäne wird ein AD-integrierter DNS verwendet.

bearbeitet 27. August 2018 von lefg

[kaineanung 14]

vor 1 Minute schrieb lefg:

Nun, dann installiere doch den 2016 in einer VM, promote ihn zum weiteren DC der Domäne, verschiebe die Rollen darauf. Falls gewollt kann der 2003 runtergestuft werden, er stört doch aber nicht, kann doch noch bleiben.

 

Ja, das war ja meine Frage: kann ich das gefahrlos machen und falls etwas schiefgehen sollte, diesen Server einfach wieder herausnehmen aus der Domäne und aus seiner Rolle?

Die anderen meinen ich soll unbedingt externe Hilfe holen. Ich würde gerne wissen ob mit meiner oben aufgezählten Vorgehensweise ich irgendwas irreperabel kaputtmachen kann?

vor 6 Minuten schrieb lefg:

Den 2003 sichern? Der wird ja nicht angefasst, also eigentlich keine Sicherung nötig, Aber Vorsicht ist die Mutter der Porzelankiste.

Ich weiß ja nicht ob der sich irgendwo irgendwas merkt und beim zurückrudern dann irgendwas falsch oder gar nicht mehr läuft?

Aber genau das wollte ich ja eigentlich erfragen.

 

[lefg 276]

vor 7 Minuten schrieb kaineanung:

Aber genau das wollte ich ja eigentlich erfragen.

Wie schon geschrieben, man muss den 2003 ja nicht gleich wegwerfen. Behalte ihn erstmal. Zum Testen des 2016 kann man den 2003 mal abtrennen. Später dann wieder verbinden mit dem Netz und wenns soweit ist herrunterstufen zum Mitgliedsserver. Wenn er nicht mehr benötigt dann aus der Domäne nehmen in eine Arbeitsgruppe Workgroup.

Zitat

 

 

 

Ein wesentlicher Punkt ist der DNS. In einer AD-Domäne wird regelmässig der DNS als AD-integriert verwendet. Anders sei denn, es gibt einen besonderen Grund, jemand möchte es so.

 

Noch ein Nachtrag beginnend mit einer Frage: Du kennst den Begriff Ereignisprotokoll, hast da schon reingeschaut und bist damit vertraut? Falls nicht, dann solltest Du dich damit befassen.

bearbeitet 27. August 2018 von lefg

[Squire 211]

@kaineanung warum will man so ein "Server-Raid" haben, wenn man schon einen kleinen ESX Cluster in Betrieb hat? Dann lieber noch zwei Kisten in den ESX Cluster und man hat das ganze Hardwaregeblödel weg (nebenbei - das Server-Raid ist auch nix anderes wie eine Virtualisierungslösung).

 

Wie das mit der Lizenzierung der Windowssysteme bei Deinem Server-Raid ausschaut hast Du Dich sicherlich schlau gemacht. Nicht dass Du dann später vom Glauben abfällst ...

 

Lieber wie gesagt zusätzliche ESXn mit entsprechenden Datacenterlizenzen ausstatten ... Software wie SQL etc hast Du ja sicherlich unter SA wenn sie auf den ESXn betrieben werden ...

[kaineanung 14]

vor 22 Minuten schrieb Squire:

 warum will man so ein "Server-Raid" haben, wenn man schon einen kleinen ESX Cluster in Betrieb hat? Dann lieber noch zwei Kisten in den ESX Cluster und man hat das ganze Hardwaregeblödel weg (nebenbei - das Server-Raid ist auch nix anderes wie eine Virtualisierungslösung).

Da gibt es bestimmt mehrere Faktoren warum man das machen würde.

Hat man alles auf der SAN, hat man alles auf der zentralen Storage. Geht die kaputt, was zwar eher unwahrscheinlich ist aber dennoch passieren kann, hat man einen Totalausfall.

Will man es mehr dezentral haben, baut man sich ein weiteres, teures SAN zusammen ODER man setzt auf die sehr günstige Lösung mit der RAID5-Serverlösung. Der Software-Unterbau ist kostenlos. Man braucht genauso viel MS-Lizenzen wie man Server betreiben will (was man bei den VMs ja auch benötigt) und die Hardware kann auch 'nur moderat' ausfallen.

Man hat eine Ausfallsicherheit die sicherlich vergleichbar mit der SAN ist (wenn nicht gar besser) und flexibler (neue Hardware nur in den Slot reinschieben und fertig) und günstiger (moderate Server reichen vollkommen aus).

 

Und auch noch ein Faktor: auch mal was anderes gesehen zu haben und es auszuprobieren..

[Squire 211]

naja - bei einem normalen SAN hab ich normalerweise die Komponenten redundant - und wenn ich das noch sicherer haben will hab ich eine gespiegelte Lösung.

Was die Lizenzierung angeht - da liegst Du falsch! Mit den entsprechenden Datacenterlizenzen und der entsprechenden Anzahl Cores kann ich soviele VMs auf einem ESX betreiben was die Hardware halt hergibt. Es ist also mitnichten eine Lizenz pro VMware nötig https://www.microsoft.com/de-de/cloud-platform/windows-server-pricing

 

[kaineanung 14]

vor 15 Stunden schrieb Squire:

Mit den entsprechenden Datacenterlizenzen und der entsprechenden Anzahl Cores kann ich soviele VMs auf einem ESX betreiben was die Hardware halt hergibt.

 

Das würde auch mit dem von mir angesprochenen System so gehen, richtig?

Was aber bei diesem RAID-System noch hinzukommt: ich brauche keine ESX-Lizenz weil der Software-'Unterbau' kostenlos ist.

Ausserdem bleiben wir ja auch bei unserer ESX-Virtualisierung. Es wird eben 'nur' das Server-RAID-System zusätzlich hinzugenommen.

Das wird wohl mit neuer Hardware passieren, wenn es aber gut wird, dann haben wir hier später noch einen Haufen an Server herumliegen die nicht schlecht sind und so genutzt werden können... und wenn es für meine Testumgebungen für 'was-auch-immer' ist.

 

Das Thema ist aber dennoch das Vorgehen bei der Migration und das will ich nochmals ansprechen:

 

1. Image vom W2K3-Server machen

2. auf neuer Hardware MS W2K16 installieren

3. AD-Rolle installieren. Eventuell DNS-Rolle ebenso sofern notwendig (und Bind9 als Master & MS Server als Slave zum transferieren aller Zonen und dann andersherum für den 'laufenden Betrieb')

4. 'Promoten' (muss mich noch einlesen wie das geht. Wird aber schon gut gehen. Ich teste es ja erst in der virtualisierten Umgebung)

5. Abwarten sobald sich alles synchronisiert hat und dann alles was auf den neuen Server delegiert werden muss dies eben tun (muss ich auch noch mal eine Auflistung machen was 'rüber' delegiert werden muss)

6. W2K3 vorsichtshalber mal herunterfahren und eine zeitlang testen ob die Domäne ohne den alten Server tut.

7. W2K3 demoten & komplett aus dem Netz nehmen.

8. Falls bei Schritt 3 es notwendig war den DNS-Server aus den MS-Server zu legen -> falls gewünscht wieder zurück transferieren auf den Bind9 (nur wenn es uns Spaß macht.. ;))

 

Habe ich das Alles erst mal richtig 'erfasst'?

Wenn ja, werde ich jetzt mal in meiner Testumgebung einen Server 2K3 installieren und diesen zum einzigen DC machen. Dann werde ich das Szenario mal durchspielen....

 

[mba 133]

Wieviele DCs sollen es nach entfernen des 2003er werden? 

[kaineanung 14]

vor 23 Minuten schrieb mba:

Wieviele DCs sollen es nach entfernen des 2003er werden? 

Nach dem entfernen des W2K3-DC sollen es 2 DCs W2K16 werden. Das sollte laut meiner Recherche für unsere Domäne mit ca. 250 Clients ausreichend sein. Notfalls kann man ja problemlos hinzufügen.

Mich würde es auch reizen einen 3. DC als Samba-DC-Server aufzuziehen. Aber das ist ferne Zukunftsmusik.

bearbeitet 28. August 2018 von kaineanung

[mba 133]

Und beide DCs auf der selben Hardware? 

[kaineanung 14]

vor 8 Minuten schrieb mba:

Und beide DCs auf der selben Hardware?

Oh nein, natürlich nicht!

 

Ich habe es weiter oben mehrfach erwähnt gehabt:

1x DC auf der ESX-SAN

1x DC auf einem separaten RAID5-Server-System (weiter oben beschrieben)

 

 

Nachtrag:

Was die Ausfallsicherheit angeht ist somit bestens abgesichert. Darüber muss man sich also nicht Sorgen. Nur die Migration selber will ich erfoglreich hinter mich bringen...

bearbeitet 28. August 2018 von kaineanung

[mba 133]

Und auf dem San läuft Windows? 

Oder in einer Vm auf dem esx mit Speicher im San? 

[monstermania 53]

vor 5 Minuten schrieb kaineanung:

1x DC auf der ESX-SAN

1x DC auf einem separaten RAID5-Server-System (weiter oben beschrieben)

 

Mal so als Hinweis. Haben das wie folgt realisiert:

1 DC als VM auf dem zentralen SAN (AD, DNS, DHCP)

1 DC als VM auf dem lokalen Platten eines der VM-Hosts (RAID-1)

Damit haben wir die Sicherheit, dass wenn das SAN mal einen Komplettchrash hat, dass zumindest die Basisdienste (AD, DNS, DHCP) noch funktionieren. 

[kaineanung 14]

vor 1 Minute schrieb mba:

Und auf dem San läuft Windows? 

Oder in einer Vm auf dem esx mit Speicher im San? 

Hat zwar nichts direkt mit der Migration zu tun aber:

momentan läuft der einzige DC-Server (W2K3) nativ auf einem Server.

Der neue 1. DC (W2K16) kommt in die ESX-SAN, der 2. DC (natürlich ebenfalls W2K16) kommt auf die Raid5-Kiste.

Die SAN ist die Storage und 2 potente Server die die VMs betreiben. Das OS der SAN ist ESX von VMWare. Die Virtuellen Maschinen sind unterschiedlich und spielen ja keine Rolle für das aktuelle unterfangen. Es sind u.a. unsere ERP-Server (AP & DB) auf Windows 2K16, DNS und DHCP auf Ubuntu 16.04 usw. die aktuell auf der SAN laufen.

Jetzt kommt eben noch ein DC hinzu...

vor 6 Minuten schrieb monstermania:

Damit haben wir die Sicherheit, dass wenn das SAN mal einen Komplettchrash hat, dass zumindest die Basisdienste (AD, DNS, DHCP) noch funktionieren. 

Da will ich auch hin. Nur eben das wir ein wenig neue Dinge testen wollen und der 2. DC eben nicht auf eine separate VM kommt sondern auf das o.g. Raid5-Server-Verbund. Ansonsten ist es ja gleich. Nein, nicht ganz: DHCP und DNS laufen bei uns auf Ubuntu Server und sind genauso realisiert wie bei euch: DHCP und Master-DNS auf der SAN, Failover-DHCP und Slave-DNS in einer VM auf einem ESXi-Host.

[Squire 211]

Moment - das kann nicht stimmen ... wenn das OS des SAN ESX von VMware sein soll ... für vSAN sind mindestens drei Nodes notwendig.