ADMT Forest Migration
Hallo Forum,
dies ist mein erster Beitrag hier und ich hoffe, ich mache alle richtig.
Ich habe folgendes Problem.
Ich soll eine Forest Migration durchführen von der Domäne Firmenname.com zu AD.Firmenname.com.
Der Quell DC ist ein Win Server 2022 Standard, der Ziel DC ist ein Win 2022 Standard. Vertrauensstellungen sind gesetzt, Auflösen der DCs vorwärts sowie rückwärts funktioniert.
Tool zur Migration ist das ADMT 3.2.
Was klappt:
-Group migration
-Users account migration
-Security Translation
Was funktioniert nicht:
-Computers account migration.
Die Clients sind alle win11 Pro.
-Windows Firewall deaktiviert
-Admin der neuen Domäne auf den Clients in der Gruppe Administrators hinterlegt
-Sicherheitssoftware Sentinal One deinstalliert.
Was passiert bei Security Translation:
Pre-Check läuft ohne Fehler durch
Pre-Check und Run Agent Operation spuckt mir folgenden Fehler im Log aus:
ERR3:7075 Failed to change domain affiliation, hr=80070791
Authentication failed because NTLM authentication has been disabled.
Per GPO habe ich NTLM zugelassen für eingehende und ausgehende Verbindungen.
-Der Post-Check wird nicht durchgeführt, da der automatisierte Reboot des Clients durch das ADMT nicht erfolgt. Das Gerät wird nicht automatisch in die neue Domäne gehoben. Gesetzte Zeit für den Neustart 1Min. Starte ich das Gerät händisch neu, passiert nichts, der Post-Check bleibt weiterhin auf nicht durchgeführt, auch wenn ich mich mit dem Gerät an der neuen Domäne Anmelde. Weiteres interessantes Phänomen, melde ich mich mit dem User an der neuen Domäne an, flackern die Icons auf dem Desktop.
Ist jemand schon einmal von Euch auf dieses Problem gestoßen?
Ein Test-Laptop, der frisch aufgesetzt war ging ohne Probleme durch.
Über Hilfe würde ich mich sehr freuen.
Beste Grüße.
dies ist mein erster Beitrag hier und ich hoffe, ich mache alle richtig.
Ich habe folgendes Problem.
Ich soll eine Forest Migration durchführen von der Domäne Firmenname.com zu AD.Firmenname.com.
Der Quell DC ist ein Win Server 2022 Standard, der Ziel DC ist ein Win 2022 Standard. Vertrauensstellungen sind gesetzt, Auflösen der DCs vorwärts sowie rückwärts funktioniert.
Tool zur Migration ist das ADMT 3.2.
Was klappt:
-Group migration
-Users account migration
-Security Translation
Was funktioniert nicht:
-Computers account migration.
Die Clients sind alle win11 Pro.
-Windows Firewall deaktiviert
-Admin der neuen Domäne auf den Clients in der Gruppe Administrators hinterlegt
-Sicherheitssoftware Sentinal One deinstalliert.
Was passiert bei Security Translation:
Pre-Check läuft ohne Fehler durch
Pre-Check und Run Agent Operation spuckt mir folgenden Fehler im Log aus:
ERR3:7075 Failed to change domain affiliation, hr=80070791
Authentication failed because NTLM authentication has been disabled.
Per GPO habe ich NTLM zugelassen für eingehende und ausgehende Verbindungen.
-Der Post-Check wird nicht durchgeführt, da der automatisierte Reboot des Clients durch das ADMT nicht erfolgt. Das Gerät wird nicht automatisch in die neue Domäne gehoben. Gesetzte Zeit für den Neustart 1Min. Starte ich das Gerät händisch neu, passiert nichts, der Post-Check bleibt weiterhin auf nicht durchgeführt, auch wenn ich mich mit dem Gerät an der neuen Domäne Anmelde. Weiteres interessantes Phänomen, melde ich mich mit dem User an der neuen Domäne an, flackern die Icons auf dem Desktop.
Ist jemand schon einmal von Euch auf dieses Problem gestoßen?
Ein Test-Laptop, der frisch aufgesetzt war ging ohne Probleme durch.
Über Hilfe würde ich mich sehr freuen.
Beste Grüße.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673108
Url: https://administrator.de/forum/forest-migration-windows-server-admt-673108.html
Ausgedruckt am: 04.06.2025 um 14:06 Uhr
9 Kommentare
Neuester Kommentar
hallo, prüfe doch mal, welche NTLM-Variante da gefordert ist:
https://www.itnator.net/ntlmv2-aktivieren-lan-manager-authentifizierung/
Was ist denn auf den Clients konfiguriert?
https://www.itnator.net/ntlmv2-aktivieren-lan-manager-authentifizierung/
Was ist denn auf den Clients konfiguriert?
Hallo miniwin,
danke für deine Antwort. Ich habe ntlm und ntlmv2 probiert für LAN Manager-Authentifizierung GPO,
Netzwerksicherheit NTLM eingehend zugelassen, ntlm ausgehend zugelassen
gpos geforced, keine Änderung.
Reg-Eintrag Wert 1 und 3 getestet
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"lmcompatibilitylevel"=dword:00000001.
und einmal
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"lmcompatibilitylevel"=dword:00000003.
Hat keine Änderung gebracht.
Bin echt ratlos langsam.
danke für deine Antwort. Ich habe ntlm und ntlmv2 probiert für LAN Manager-Authentifizierung GPO,
Netzwerksicherheit NTLM eingehend zugelassen, ntlm ausgehend zugelassen
gpos geforced, keine Änderung.
Reg-Eintrag Wert 1 und 3 getestet
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"lmcompatibilitylevel"=dword:00000001.
und einmal
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"lmcompatibilitylevel"=dword:00000003.
Hat keine Änderung gebracht.
Bin echt ratlos langsam.
Der Imcompatibilitylevel sollte 4 oder 5 sein.
https://ss64.com/nt/syntax-ntlm.html
https://ss64.com/nt/syntax-ntlm.html
Hi,
wir nutzen auch noch ADMT für sowas, aber Computer migrieren wir damit nicht mehr. Auch wegen der Inkompatibilitäten des Agents, welche meines Wissens aber bereits seit Win7 oder gar Vista bestehen.
Das Aufwand-Nutzen-Verhältnis ist einfach zu schlecht. Da ADMT bei Interforest-Migration eh alle Konten kopiert und nicht verschiebt und das bei Computerkonten sogar bei Intraforest-Migrationen so ist, legen wir die Computerkonten entweder manuell oder per Scripte vorher in der neuen Domäne an, inkl. Gruppenmitgliedschaften und vorbereiteter GPO's. Dann lassen wir die Computer der neuen Domäne beitreten, ebenso entweder manuell oder per Scripte. Wenn die Benutzerkonten vorher bereits inkl. sidHistory migriert worden sind, dann übernehmen die migrierten Konten bei Anmeldung an den PC die vorgerigen Benutzetrprofile 1:1.
E.
wir nutzen auch noch ADMT für sowas, aber Computer migrieren wir damit nicht mehr. Auch wegen der Inkompatibilitäten des Agents, welche meines Wissens aber bereits seit Win7 oder gar Vista bestehen.
Das Aufwand-Nutzen-Verhältnis ist einfach zu schlecht. Da ADMT bei Interforest-Migration eh alle Konten kopiert und nicht verschiebt und das bei Computerkonten sogar bei Intraforest-Migrationen so ist, legen wir die Computerkonten entweder manuell oder per Scripte vorher in der neuen Domäne an, inkl. Gruppenmitgliedschaften und vorbereiteter GPO's. Dann lassen wir die Computer der neuen Domäne beitreten, ebenso entweder manuell oder per Scripte. Wenn die Benutzerkonten vorher bereits inkl. sidHistory migriert worden sind, dann übernehmen die migrierten Konten bei Anmeldung an den PC die vorgerigen Benutzetrprofile 1:1.
E.
ADMT 3.2 unterstützt laut Microsoft weder Windows 11 noch Server 2022, da es die veränderte Sicherheit in den neueren Windows-Versionen noch nicht supported. An anderer Stelle wird erwähnt, daß es TLS 1.0 gegenüber SQL-Servern nutzen muß und für die Migrierung unconstrained delegation benötigt, eine Vorgehensweise, die Microsoft für nicht mehr erlaubt. Da sind Probleme vorprogrammiert, wenn man das so auf nicht unterstützten Betriebssystemversionen in der Domäne einsetzt.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-dir ...
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-dir ...
ADMT ist meines Wissens auch abgekündigt und wird nicht weiterentwickelt. Wir haben genau dafür ne alte VM mit alten Windows und SQL Server Versionen am Laufen, welche nur bei Bedarf gestartet wird und netzwerktechnisch maximal abgeschottet ist.
Hallo Zusammen,
tut mir leid, das ich erst recht spät antworte, etwas viel zu tun im Büro.
@miniwin
Danke, werde ich testen.
@emeriks und @minwin
Besten Dank. Ja, es stimmt, dass das nicht mehr weiterentwickelt wird, hatte aber auf einer Schulung mit einem MS Trainer gesprochen gehabt, er meinte das kann ich nutzen und sollte keine Probleme machen. Die User-Migration war überhaupt kein Problem, dass lief anstandslos durch.
@emeriks
"Das Aufwand-Nutzen-Verhältnis ist einfach zu schlecht. Da ADMT bei Interforest-Migration eh alle Konten kopiert und nicht verschiebt und das bei Computerkonten sogar bei Intraforest-Migrationen so ist, legen wir die Computerkonten entweder manuell oder per Scripte vorher in der neuen Domäne an, inkl. Gruppenmitgliedschaften und vorbereiteter GPO's. Dann lassen wir die Computer der neuen Domäne beitreten, ebenso entweder manuell oder per Scripte. Wenn die Benutzerkonten vorher bereits inkl. sidHistory migriert worden sind, dann übernehmen die migrierten Konten bei Anmeldung an den PC die vorgerigen Benutzetrprofile 1:1."
Zu den Geräten, Ihr exportiert euch dann eine CSV und importiert diese dann wieder oder wie macht Ihr das?
Auf jeden Fall besten Dank für Eure Beteiligung.
tut mir leid, das ich erst recht spät antworte, etwas viel zu tun im Büro.
@miniwin
Danke, werde ich testen.
@emeriks und @minwin
Besten Dank. Ja, es stimmt, dass das nicht mehr weiterentwickelt wird, hatte aber auf einer Schulung mit einem MS Trainer gesprochen gehabt, er meinte das kann ich nutzen und sollte keine Probleme machen. Die User-Migration war überhaupt kein Problem, dass lief anstandslos durch.
@emeriks
"Das Aufwand-Nutzen-Verhältnis ist einfach zu schlecht. Da ADMT bei Interforest-Migration eh alle Konten kopiert und nicht verschiebt und das bei Computerkonten sogar bei Intraforest-Migrationen so ist, legen wir die Computerkonten entweder manuell oder per Scripte vorher in der neuen Domäne an, inkl. Gruppenmitgliedschaften und vorbereiteter GPO's. Dann lassen wir die Computer der neuen Domäne beitreten, ebenso entweder manuell oder per Scripte. Wenn die Benutzerkonten vorher bereits inkl. sidHistory migriert worden sind, dann übernehmen die migrierten Konten bei Anmeldung an den PC die vorgerigen Benutzetrprofile 1:1."
Zu den Geräten, Ihr exportiert euch dann eine CSV und importiert diese dann wieder oder wie macht Ihr das?
Auf jeden Fall besten Dank für Eure Beteiligung.
Zu den Geräten, Ihr exportiert euch dann eine CSV und importiert diese dann wieder oder wie macht Ihr das?
Über welchen Umweg, ist vollkommen egal. Wichtig ist, dass Ihr wisst, was übertragen werden muss. Die üblichen Verdächtigen sollten sein- Name (ist klar)
- Beschreibung
- Gruppenmitgliedschaft
Übertrage heißt, in der neuen Domäne für jeden aus der alten Domäne ausgelesenen Computer ein neues, deaktiviertes Computerkonto mit selben Namen erstellen und anschließend die relevanten Attribute übertragen. Die Gruppenmitgliedschaft muss ggf. auf die Gruppen der Zieldomäne "umgerechnet" werden.
Für Computer relevante Gruppenrichtlinien kann man exportieren und wieder importieren. Man muss nur ggf. die Sicherheits- und/oder ITL-Filter anpassen.
Am besten checkst Du in der neuen Domäne erst mal, ob die Gruppe(n), wo die PCs hinein müssen, existieren und die passenden GPOs haben. Wenn bei den GPOs was fehlt, diese aus der alten Domäne exportieren und in die neue importieren und der jeweiligen Gruppe zuordnen. Ist das vorbereitet, kannst Du einen ersten PC mit einem Powershell-Skript testweise rübernehmen und wenn das gutgeht, den Rest angehen.
