7
Probleme beim Migrieren von Server 2019 Standard zu 2022 Standard
Hallo Zusammen,
wir sind gerade dabei einen Server 2019 (SRVDC3) Standard zu einen Server 2022 Standard (SRVDC5) zu immigrieren. Folgendermaßen sind wir vorgegangen. Server 2022 in die Domäne aufgenommen. Active Directory Domänendienste installiert. Dann zum Domänencontroller hochgestuft. Mit ntdsutil die FSMO Rollen auf den neuen Server 2022 übertragen. NTDS Settings Replizierung abgewartet.
Jetzt kommt mein Problem, wenn ich den neuen Server 2022 alleine starte und mich anmelden möchte kommt die Meldung „Das Kennwort ist falsch“. Ich kann mich am neuen Server nicht anmelden solange der Server 2019 nicht läuft.
Folgende Dinge habe ich überprüft:
Und hier noch DCDIAG
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = SRVDC5
wir sind gerade dabei einen Server 2019 (SRVDC3) Standard zu einen Server 2022 Standard (SRVDC5) zu immigrieren. Folgendermaßen sind wir vorgegangen. Server 2022 in die Domäne aufgenommen. Active Directory Domänendienste installiert. Dann zum Domänencontroller hochgestuft. Mit ntdsutil die FSMO Rollen auf den neuen Server 2022 übertragen. NTDS Settings Replizierung abgewartet.
Jetzt kommt mein Problem, wenn ich den neuen Server 2022 alleine starte und mich anmelden möchte kommt die Meldung „Das Kennwort ist falsch“. Ich kann mich am neuen Server nicht anmelden solange der Server 2019 nicht läuft.
Folgende Dinge habe ich überprüft:
Und hier noch DCDIAG
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = SRVDC5
- Identifizierte AD-Gesamtstruktur.
Erforderliche Anfangstests werden ausgeführt.
Server wird getestet: Standardname-des-ersten-Standorts\SRVDC5
Starting test: Connectivity
......................... SRVDC5 hat den Test Connectivity bestanden.
Primärtests werden ausgeführt.
Server wird getestet: Standardname-des-ersten-Standorts\SRVDC5
Starting test: Advertising
......................... SRVDC5 hat den Test Advertising bestanden.
Starting test: FrsEvent
......................... SRVDC5 hat den Test FrsEvent bestanden.
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden.
Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
......................... Der Test DFSREvent für SRVDC5 ist fehlgeschlagen.
Starting test: SysVolCheck
......................... SRVDC5 hat den Test SysVolCheck bestanden.
Starting test: KccEvent
......................... SRVDC5 hat den Test KccEvent bestanden.
Starting test: KnowsOfRoleHolders
......................... SRVDC5 hat den Test KnowsOfRoleHolders bestanden.
Starting test: MachineAccount
......................... SRVDC5 hat den Test MachineAccount bestanden.
Starting test: NCSecDesc
......................... SRVDC5 hat den Test NCSecDesc bestanden.
Starting test: NetLogons
......................... SRVDC5 hat den Test NetLogons bestanden.
Starting test: ObjectsReplicated
......................... SRVDC5 hat den Test ObjectsReplicated bestanden.
Starting test: Replications
......................... SRVDC5 hat den Test Replications bestanden.
Starting test: RidManager
......................... SRVDC5 hat den Test RidManager bestanden.
Starting test: Services
......................... SRVDC5 hat den Test Services bestanden.
Starting test: SystemLog
......................... SRVDC5 hat den Test SystemLog bestanden.
Starting test: VerifyReferences
......................... SRVDC5 hat den Test VerifyReferences bestanden.
Partitionstests werden ausgeführt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: WK
Starting test: CheckSDRefDom
......................... WK hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... WK hat den Test CrossRefValidation bestanden.
Unternehmenstests werden ausgeführt auf: WK.local
Starting test: LocatorCheck
......................... WK.local hat den Test LocatorCheck bestanden.
Starting test: Intersite
......................... WK.local hat den Test Intersite bestanden.
Ich hoffe das ist hier nicht zu viel Input auf einmal. Vielleicht hat ja jemand von euch schon mal so ein Problem gehabt. Oder kann sagen ob wir hier noch etwas vergessen haben.
Danke schon mal
Gruß
Christian
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: 671573
Url: https://administrator.de/forum/probleme-beim-migrieren-von-server-2019-standard-zu-2022-standard-671573.html
Ausgedruckt am: 23.02.2025 um 17:02 Uhr
7 Kommentare
Neuester Kommentar
Moin,
was sagen denn die Ereignisprotokolle, gibt es da noch Fehlermeldungen? Hört sich erst mal so an, als sei da doch nicht alles sauber repliziert.
Ist die Reihenfolge der Nameserver geändert (siehe auch www.escde.net/blog/migration-eines-domain-controllers-von-windows-server-2012-r2-auf-windows-server-2022?
Gruß
DivideByZero
P.S.: Das, was Du machst, ist wohl kaum eine Immigration 😉.
was sagen denn die Ereignisprotokolle, gibt es da noch Fehlermeldungen? Hört sich erst mal so an, als sei da doch nicht alles sauber repliziert.
Ist die Reihenfolge der Nameserver geändert (siehe auch www.escde.net/blog/migration-eines-domain-controllers-von-windows-server-2012-r2-auf-windows-server-2022?
Gruß
DivideByZero
P.S.: Das, was Du machst, ist wohl kaum eine Immigration 😉.
Hallo,
ich würde auch auf dns tippen und folgende Liste durchgehen:
Ipconfig des neuen Servers prüfen ob der im dns den alten Server vor sich selbst drinstehen hat.
Was ist mit anderen Client, können die sich anmelden wenn nur der neue Server läuft?
ipv6 auf der nic deaktivieren, nslookup domain.local prüfen, azure arc feature entfernen
Ich schließe mal aus dass der neue Server auf DHCP statt statischer Adresse steht, das würde das Phänomen aber ggf. auch erklären wenn der alte Server die DHCP-Rolle hatte und sich selbst als DNS-Server verteilt.
ich würde auch auf dns tippen und folgende Liste durchgehen:
Ipconfig des neuen Servers prüfen ob der im dns den alten Server vor sich selbst drinstehen hat.
Was ist mit anderen Client, können die sich anmelden wenn nur der neue Server läuft?
ipv6 auf der nic deaktivieren, nslookup domain.local prüfen, azure arc feature entfernen
Ich schließe mal aus dass der neue Server auf DHCP statt statischer Adresse steht, das würde das Phänomen aber ggf. auch erklären wenn der alte Server die DHCP-Rolle hatte und sich selbst als DNS-Server verteilt.
Hallo, hier mal Ipconfig des neuen Server:
Moin,
Z.B. https://learn.microsoft.com/en-us/answers/questions/1106238/dcs-failed-t ...
Ansonsten: welcher Parchstand Verrat auf dem 2022er?
Der Test DFSREvent für SRVDC5 ist fehlgeschlagen.
Da musst du mal auf die Suche gehen.Z.B. https://learn.microsoft.com/en-us/answers/questions/1106238/dcs-failed-t ...
Ansonsten: welcher Parchstand Verrat auf dem 2022er?
Ist das vermutlich ein Dellserver bei dem idrac noch nicht konfiguriert ist oder zukünftig auch nicht genutzt werden soll?
Falls ja, würde ich zur Fehlerdiagnose temporär die zweite nic(remote ndis) deaktivieren um lokale DNS-Probleme damit auszuschließen. Neustarten und nochmal dcdiag laufen lassen.
Falls ja, würde ich zur Fehlerdiagnose temporär die zweite nic(remote ndis) deaktivieren um lokale DNS-Probleme damit auszuschließen. Neustarten und nochmal dcdiag laufen lassen.
Mahlzeit.
Das eingesetzte Subnetz 172.40.10.0/24 gehört T-Mobile in den USA.
Bitte für lokale Netze dem RFC Standard folgen.
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Auch .local als Domänen-Suffix solltest du lieber schwärzen sonst hagelt es Kritik
Würde hier, wie @wollekuj schrieb, mal testweise die zweite NIC deaktivieren.
Nimm mal den alten DNS Server aus der IP Konfiguration deiner primären NIC.
Ist der DNS auch sauber vom alten DC "bereinigt" worden? Dieser hat aber die Domänen Dienste noch installiert, korrekt?
Können sich Clients an ihren PC anmelden und klappt die Namensauflösung über den neuen DC?
Welche Gesamtstrukturebene ist denn gegeben?
Gruß
Marc
Das eingesetzte Subnetz 172.40.10.0/24 gehört T-Mobile in den USA.
Bitte für lokale Netze dem RFC Standard folgen.
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Auch .local als Domänen-Suffix solltest du lieber schwärzen sonst hagelt es Kritik
Würde hier, wie @wollekuj schrieb, mal testweise die zweite NIC deaktivieren.
Nimm mal den alten DNS Server aus der IP Konfiguration deiner primären NIC.
Ist der DNS auch sauber vom alten DC "bereinigt" worden? Dieser hat aber die Domänen Dienste noch installiert, korrekt?
Können sich Clients an ihren PC anmelden und klappt die Namensauflösung über den neuen DC?
Welche Gesamtstrukturebene ist denn gegeben?
Gruß
Marc
Nabend,
wie sieht es in der DNS Verwaltung der Zone "wk.local" aus? Steht dort ggf. noch ein ältere DC mit drin? Wie die Kollegen schon geschrieben haben IPv6 aus und die Remote NDIS NIC der IDRAC weg/deaktivieren...
Dein neuer DC wird IPv6 priorisieren und darüber DNS abfragen versuchen, das läuft dann ins Chaos
Gruß
wie sieht es in der DNS Verwaltung der Zone "wk.local" aus? Steht dort ggf. noch ein ältere DC mit drin? Wie die Kollegen schon geschrieben haben IPv6 aus und die Remote NDIS NIC der IDRAC weg/deaktivieren...
Dein neuer DC wird IPv6 priorisieren und darüber DNS abfragen versuchen, das läuft dann ins Chaos
Gruß
