12
DC InPlace Update
Hallo,
wir stehen gerade vor einem OS Update unserer 2012 DomainController.
DC1 hält alle FSMO Rollen. DC2 läuft in der selben Site.
Zudem gibt es weitere 4 DCs an Außenstandorten, welche jedoch bereits auf 2016 oder 2019 laufen (2 mit extrem langsamer VPN Anbindung).
Wir haben bereits bei ca 50 VMs (Filer und Applikationsserver) erfolgreich ein Inplace Update von 2012 auf 2022 durchgeführt.
Beim DC haben wir uns das bislang noch nicht getraut.
Hat das von euch schon jemand durchgeführt? Gibt’s Stolpersteine?
Erst FSMO Rollen wegschieben? Oder doch als erstes den mit den Rollen Updaten?
Hauptgrund warum wir auf ein Inplace Update zielen ist bei uns DNS. Es dürften knapp 1000 Systeme sein, welche als DNS Server die beiden IPs dieser DCs eingetragen haben.
Was mich dann zur nächsten Frage bringt: Wie habt ihr das gelöst falls ein neuer DC mit anderer IP in Spiel kam?
Auch vorstellbar: Alten DC1 sauber entfernen und neuen unter gleichem Namen und IP bereitstellen!?
Wie schnell hat das AD den ersten DC1 vergessen?
Oder anderer Name aber selbe IP?
Danke und Gruß
wir stehen gerade vor einem OS Update unserer 2012 DomainController.
DC1 hält alle FSMO Rollen. DC2 läuft in der selben Site.
Zudem gibt es weitere 4 DCs an Außenstandorten, welche jedoch bereits auf 2016 oder 2019 laufen (2 mit extrem langsamer VPN Anbindung).
Wir haben bereits bei ca 50 VMs (Filer und Applikationsserver) erfolgreich ein Inplace Update von 2012 auf 2022 durchgeführt.
Beim DC haben wir uns das bislang noch nicht getraut.
Hat das von euch schon jemand durchgeführt? Gibt’s Stolpersteine?
Erst FSMO Rollen wegschieben? Oder doch als erstes den mit den Rollen Updaten?
Hauptgrund warum wir auf ein Inplace Update zielen ist bei uns DNS. Es dürften knapp 1000 Systeme sein, welche als DNS Server die beiden IPs dieser DCs eingetragen haben.
Was mich dann zur nächsten Frage bringt: Wie habt ihr das gelöst falls ein neuer DC mit anderer IP in Spiel kam?
Auch vorstellbar: Alten DC1 sauber entfernen und neuen unter gleichem Namen und IP bereitstellen!?
Wie schnell hat das AD den ersten DC1 vergessen?
Oder anderer Name aber selbe IP?
Danke und Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3876609032
Url: https://administrator.de/contentid/3876609032
Ausgedruckt am: 19.12.2024 um 04:12 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Anschließend den DC, der nicht die FSMO-Rollen etc. inne hatte, demotet und sauber aus dem AD entfernt, sowie noch die Eventlogs geprüft.
Ein... zwei Tage später einen neuen Server aufgesetzt, der die IP des alten DCs bekommen hatte; zum DC promoted und die Replikation abgewartet nebst den checks der Eventlogs.
Als alles lief, die FSMO-Rollen & Co. auf den neuen verschoben - Logs gecheckt.
Wieder keine Fehler gehabt: Dann den ersten DC herabgestuft und aus dem AD entfernt. Logs gecheckt.
Nun einen weiteren, neuen Server hochgezogen, den zum DC promoted (und ihm vorher die IP des ersten DCs gegeben). Replikation abgewartet/ geprüft.
Das Setup ein paar Tage laufen lassen und nach rund 3-5 Tagen den temporären DC wieder vom Netz genommen...
So hatten wir eigentlich immer zwei DCs online . wobei ihr ja noch vier weitere an anderen Standorten verteilt habt....
Gruß
em-pie
Edit: Typo
Was mich dann zur nächsten Frage bringt: Wie habt ihr das gelöst falls ein neuer DC mit anderer IP in Spiel kam?
Wir haben einen dritten (temporären) DC ins Spiel gebracht. Den hochgestuft und die Replikation abgewartet.Anschließend den DC, der nicht die FSMO-Rollen etc. inne hatte, demotet und sauber aus dem AD entfernt, sowie noch die Eventlogs geprüft.
Ein... zwei Tage später einen neuen Server aufgesetzt, der die IP des alten DCs bekommen hatte; zum DC promoted und die Replikation abgewartet nebst den checks der Eventlogs.
Als alles lief, die FSMO-Rollen & Co. auf den neuen verschoben - Logs gecheckt.
Wieder keine Fehler gehabt: Dann den ersten DC herabgestuft und aus dem AD entfernt. Logs gecheckt.
Nun einen weiteren, neuen Server hochgezogen, den zum DC promoted (und ihm vorher die IP des ersten DCs gegeben). Replikation abgewartet/ geprüft.
Das Setup ein paar Tage laufen lassen und nach rund 3-5 Tagen den temporären DC wieder vom Netz genommen...
So hatten wir eigentlich immer zwei DCs online . wobei ihr ja noch vier weitere an anderen Standorten verteilt habt....
Gruß
em-pie
Edit: Typo
Moin...
ich würde eine neue VM erstellen, und dort die fmso rollen hinschieben und gut ist!
Frank
ich würde eine neue VM erstellen, und dort die fmso rollen hinschieben und gut ist!
Alten DC1 sauber entfernen und neuen unter gleichem Namen und IP bereitstellen!?
das mach keinen sinn... und muss auch nicht sein!Hauptgrund warum wir auf ein Inplace Update zielen ist bei uns DNS. Es dürften knapp 1000 Systeme sein, welche als DNS Server die beiden IPs dieser DCs eingetragen haben.
was ja kein problem darstellt... das kannst du per PS Script und GPO ändern, ohne dich zu bewegen... oder zumindest nur die Finger Frank
Ich empfehle wie Vision2015 einen neuen DC aufzusetzen, so hat man keine "Altlasten" an Bord. Dann die FSMO-Rollen verschieben. Diese "knapp 100 Systeme" bekommen die IP-Adresse der DNS-Server wie? DHCP? Wenn ja, dort einfach austauschen. Wenn die Systeme aber fixe DNS-Einträge haben, dann entweder Skript oder übergangsweise die IP-Adresse des alten DC dem neuen zuweisen als weiterer virtueller NIC.
Moin,
Gruß,
Dani
ich würde eine neue VM erstellen, und dort die fmso rollen hinschieben und gut ist!
ich würde im Anschluss die IP-Adresse des bisherigen DCs der neuen VM konfigurieren und dem alten DC eine temporäre IP-Adresse vergeben - fertig. Dauert keine 60 Minuten. Machen wir so seit Jahren um den ganzen Firewall Anpassungen und den Nacharbeiten aus dem Weg zu gehen.Gruß,
Dani
Hallo,
knapp 1000 (Faktor 10!) .
Davon ca 200 Windows Server wo die IPs per Hand vergeben sind.
Ich kam noch nie auf die Idee das per GPO zu vergebeben > werde ich mir aber mal anschauen.
Allerdings sind diese das kleinere Übel.
Von Stempeluhren, über SPSen bis Werkzeugmaschinen, Klimananlagen, USVen ist da alles dabei. Laut den Kollegen kann man bei einigen auch nur einen einzigen DNS Server hinterlegen. Also recht viel "Spezial" Zeugs, was auch leider teilweise nicht in IT Hand liegt.
Von daher wäre es echt cool wenn man die IP ziemlich schnell wieder für DNS verwenden kann. Bei der letzten Migration wo es neue DCs unter anderer IP gab, hatten wir über 4 Monate wenig Spaß...
(Die DHCP Clients habe ich nicht erwähnt da ja... - selbsterklärend )
Nochmals zur ursprünglichen Frage: Hat das mal jemand per Inplace probiert???
Gruß und Dank
knapp 1000 (Faktor 10!) .
Davon ca 200 Windows Server wo die IPs per Hand vergeben sind.
Ich kam noch nie auf die Idee das per GPO zu vergebeben > werde ich mir aber mal anschauen.
Allerdings sind diese das kleinere Übel.
Von Stempeluhren, über SPSen bis Werkzeugmaschinen, Klimananlagen, USVen ist da alles dabei. Laut den Kollegen kann man bei einigen auch nur einen einzigen DNS Server hinterlegen. Also recht viel "Spezial" Zeugs, was auch leider teilweise nicht in IT Hand liegt.
Von daher wäre es echt cool wenn man die IP ziemlich schnell wieder für DNS verwenden kann. Bei der letzten Migration wo es neue DCs unter anderer IP gab, hatten wir über 4 Monate wenig Spaß...
(Die DHCP Clients habe ich nicht erwähnt da ja... - selbsterklärend
)Nochmals zur ursprünglichen Frage: Hat das mal jemand per Inplace probiert???
Gruß und Dank
Moin,
Spätestens beim nächsten Microsoft Update hast du (temporärer) Ausfall des DNS-Servers. Je nachdem was danach wieder nicht funktioniert. Was somit wieder ein Impact hervorrufen würde/wird.
Gruß,
Dani
Laut den Kollegen kann man bei einigen auch nur einen einzigen DNS Server hinterlegen. Also recht viel "Spezial" Zeugs, was auch leider teilweise nicht in IT Hand liegt.
für solche Geräte verstecken wir die DNS-Server hinter Load Balancer. Somit ist erstmal eine gewisse Hochverfügbarkeit gewährleistet. Des weiteren bekommen die Geräte den Wechsel von DNS-Server nicht mit. Was viel Zeit und Nerven spart.Spätestens beim nächsten Microsoft Update hast du (temporärer) Ausfall des DNS-Servers. Je nachdem was danach wieder nicht funktioniert. Was somit wieder ein Impact hervorrufen würde/wird.
Gruß,
Dani
InPlace-Upgrade eines DCs wäre mir zu heikel. Vor allem von 2012 (R2?) auf 2019 oder gar 2022. Einen Applikations-Server von Windows Server 2016 STD auf Windows Server 2019 DC hatte ich schon durchgeführt. Wenn du das versuchen möchtest, dann vorher noch lieber eine Vollsicherung machen.
Moin,
Loadbalancer für DNS, IPs per GPO, ... nehme ich mal alles in die Planung auf.
Gibt's auch was für LDAP Settings?
Wir haben jeweils die lokalen DCs im LDAP konfiguriert, da die externen DCs immer ewig gebraucht haben, wenn sie angesprochen werden (das VPN bzw die dortige Internetanbindung ist einfach zu langsam).
Nen Alias nutzen???
War alles bisher schon hilfreich.
Gruß
Loadbalancer für DNS, IPs per GPO, ... nehme ich mal alles in die Planung auf.
Gibt's auch was für LDAP Settings?
Wir haben jeweils die lokalen DCs im LDAP konfiguriert, da die externen DCs immer ewig gebraucht haben, wenn sie angesprochen werden (das VPN bzw die dortige Internetanbindung ist einfach zu langsam).
Nen Alias nutzen???
War alles bisher schon hilfreich.
Gruß
Moin,
Gruß,
Dani
Gibt's auch was für LDAP Settings?
ja, Standortzuordnung der Clients bzw. DCs im Verbindung mit dem verwendeten IP Subnetzen verwenden.Gruß,
Dani
Hallo,
Selbstverständlich sind die Subnetze den entsprechenden Sites/DCs zugeordnet.
Ein Ping von einem Windows System auf die Domäne liefert auch immer den lokalen DC zurück.
Trage ich bei unserem Storagesystem im LDAP Pfad die Domain ein, so nimmt er sich einen der DCs round robin technisch. Gleiches verhalten bei diversen anderen Systemen.
Daher haben wir dann den lokalen DC per Name eingetragen.
Stimmt da was nicht? Sollte sich das auch nach den Sites richten?
Gruß
Zitat von @Dani:
ja, Standortzuordnung der Clients bzw. DCs im Verbindung mit dem verwendeten IP Subnetzen verwenden.
Wie genau meinst du das?ja, Standortzuordnung der Clients bzw. DCs im Verbindung mit dem verwendeten IP Subnetzen verwenden.
Selbstverständlich sind die Subnetze den entsprechenden Sites/DCs zugeordnet.
Ein Ping von einem Windows System auf die Domäne liefert auch immer den lokalen DC zurück.
Trage ich bei unserem Storagesystem im LDAP Pfad die Domain ein, so nimmt er sich einen der DCs round robin technisch. Gleiches verhalten bei diversen anderen Systemen.
Daher haben wir dann den lokalen DC per Name eingetragen.
Stimmt da was nicht? Sollte sich das auch nach den Sites richten?
Gruß
Moin,
Gruß,
Dani
trage ich bei unserem Storagesystem im LDAP Pfad die Domain ein, so nimmt er sich einen der DCs round robin technisch. Gleiches verhalten bei diversen anderen Systemen.
du hast bis dato nicht genannt, um welche Systeme es dabei geht. Daher habe ich ins Schwarze geschossen. Bei Storage Systemen gibt es je nach Hersteller auch Möglichkeiten, das zu steuern. Bei diversen anderen Systemen kommt es darauf an. Da wären die Produkte und Herstellernamen interessant, um evtl. Möglichkeiten aufzeigen zu können.Gruß,
Dani
Hallo,
Da das Verhalten auf allen mir bekannten Systemen identisch war, bin ich davon ausgegangen, dass dies bei LDAP einfach so ist.
Bei dem Storage-System hatten wir zu diesem Thema den Hersteller mit im Boot. Lösung war halt die DCs direkt einzutragen.
Unabhängig davon:
Der aktuelle Plan sieht nun danach aus, dass wir die alten DCs sauber aus der Domäne entfernen und unter gleichem Namen und IP wieder zur Verfügung stellen (Kurzfassung).
Dann umgehen wir die Probleme mit dem LDAP und den manuellen DNS IPs.
Gruß
Zitat von @Dani:
du hast bis dato nicht genannt, um welche Systeme es dabei geht. Daher habe ich ins Schwarze geschossen.
du hast bis dato nicht genannt, um welche Systeme es dabei geht. Daher habe ich ins Schwarze geschossen.
Da das Verhalten auf allen mir bekannten Systemen identisch war, bin ich davon ausgegangen, dass dies bei LDAP einfach so ist.
Bei dem Storage-System hatten wir zu diesem Thema den Hersteller mit im Boot. Lösung war halt die DCs direkt einzutragen.
Unabhängig davon:
Der aktuelle Plan sieht nun danach aus, dass wir die alten DCs sauber aus der Domäne entfernen und unter gleichem Namen und IP wieder zur Verfügung stellen (Kurzfassung).
Dann umgehen wir die Probleme mit dem LDAP und den manuellen DNS IPs.
Gruß
