20
Nach ADMT Migration Gruppenzugehörigkeit und Optionen durcheinander
Guten Morgen @ all! 
Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen. Nun ist aber das Problem das die Nutzer andere Gruppenzugehörigkeiten haben.
Vorher waren sie reine Domänen-Gäste und nun sind sie ganz normale Domänennutzer und das muss wieder geändert werden, da dies eine sehr restriktive Umgebung ist und ein bestimmer sync von außerhalb an dieser Gruppe hängt.
Dazu kommt das die Nutzer die Option hatten das die Kennwörter nie ablaufen, genau das ist aber nun geschehen und das wird zu sehr großen Problemen führen.
Kann mir einer einen Tip geben was schief gelaufen sein könnte?
Vielen Dank im Voraus.
( Migration erfolgte von einem Windows Server 2008 auf einen Windows Server 2016.)
Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen. Nun ist aber das Problem das die Nutzer andere Gruppenzugehörigkeiten haben.
Vorher waren sie reine Domänen-Gäste und nun sind sie ganz normale Domänennutzer und das muss wieder geändert werden, da dies eine sehr restriktive Umgebung ist und ein bestimmer sync von außerhalb an dieser Gruppe hängt.
Dazu kommt das die Nutzer die Option hatten das die Kennwörter nie ablaufen, genau das ist aber nun geschehen und das wird zu sehr großen Problemen führen.
Kann mir einer einen Tip geben was schief gelaufen sein könnte?
Vielen Dank im Voraus.
( Migration erfolgte von einem Windows Server 2008 auf einen Windows Server 2016.)
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: 476918
Url: https://administrator.de/forum/nach-admt-migration-gruppenzugehoerigkeit-und-optionen-durcheinander-476918.html
Ausgedruckt am: 04.04.2025 um 11:04 Uhr
20 Kommentare
Neuester Kommentar
Hi,
Zweitens: Wenn meine Vermutung richtig ist, und das zwei getrennte Forest sind, dann kannst Du jederzeit von vorn anfangen. Also alle Benutzer nochmal löschen und noch einmal migrieren.
Ansonsten: Ein Powershell-Script, was die Gruppenmitglöiedschaften in der neuen Domäne mit der der alten vergleicht und ggf. korrigiert.
Ich nehme an, Du hast zuerst die Gruppen migriert. Und erst im zweiten Schritt die Benutzer? Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft migriert und angepasst werden soll? ("fix ... membership")
E.
Zitat von @Hendrik2586:
Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen.
Das liest sich wie: Inter Forest Migration?Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen.
Nun ist aber das Problem das die Nutzer andere Gruppenzugehörigkeiten haben.
Erstens testet man sowas vorher.Zweitens: Wenn meine Vermutung richtig ist, und das zwei getrennte Forest sind, dann kannst Du jederzeit von vorn anfangen. Also alle Benutzer nochmal löschen und noch einmal migrieren.
Ansonsten: Ein Powershell-Script, was die Gruppenmitglöiedschaften in der neuen Domäne mit der der alten vergleicht und ggf. korrigiert.
Dazu kommt das die Nutzer die Option hatten das die Kennwörter nie ablaufen, genau das ist aber nun geschehen und das wird zu sehr großen Problemen führen.
Diese Einstellung steht im userAccountControl. Keine Ahnung, ob man das auch mit ADMT migrieren kann. Das ist ja kein "normales" Attribut. Aber Du kannst es ja mal versuchen. Das muss man explizit angeben.Ich nehme an, Du hast zuerst die Gruppen migriert. Und erst im zweiten Schritt die Benutzer? Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft migriert und angepasst werden soll? ("fix ... membership")
E.
Zitat von @emeriks:
Hi,
Zweitens: Wenn meine Vermutung richtig ist, und das zwei getrennte Forest sind, dann kannst Du jederzeit von vorn anfangen. Also alle Benutzer nochmal löschen und noch einmal migrieren.
Ansonsten: Ein Powershell-Script, was die Gruppenmitglöiedschaften in der neuen Domäne mit der der alten vergleicht und ggf. korrigiert.
Ich nehme an, Du hast zuerst die Gruppen migriert. Und erst im zweiten Schritt die Benutzer? Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft migriert und angepasst werden soll? ("fix ... membership")
E.
Hi,
Zitat von @Hendrik2586:
Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen.
Das liest sich wie: Inter Forest Migration?Ich habe erfolgreich per ADMT und Pes 25.000 Nutzer von einem alten in eine neue Domäne exportieren bzw. kopieren lassen.
Nun ist aber das Problem das die Nutzer andere Gruppenzugehörigkeiten haben.
Erstens testet man sowas vorher.Zweitens: Wenn meine Vermutung richtig ist, und das zwei getrennte Forest sind, dann kannst Du jederzeit von vorn anfangen. Also alle Benutzer nochmal löschen und noch einmal migrieren.
Ansonsten: Ein Powershell-Script, was die Gruppenmitglöiedschaften in der neuen Domäne mit der der alten vergleicht und ggf. korrigiert.
Dazu kommt das die Nutzer die Option hatten das die Kennwörter nie ablaufen, genau das ist aber nun geschehen und das wird zu sehr großen Problemen führen.
Diese Eionstellung steht im userAccountControl. Keine Ahnung, ob man das auch mit ADMT migrieren kann. Das ist ja kein "normales" Attribut. Aber Du kannst es ja mal versuchen. Das muss man explizit angeben.Ich nehme an, Du hast zuerst die Gruppen migriert. Und erst im zweiten Schritt die Benutzer? Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft migriert und angepasst werden soll? ("fix ... membership")
E.
Die Gruppen habe ich nicht umziehen lassen da hier mit Standardgruppen gearbeitet wird die auch bereits in der neuen Struktur vorhanden sind.
Das ADMT lässt eigentlich zu das alles User Accounts so übernommen werden wie sie in der alten Domäne sind. Ich hab das extra alles angeglichen.
Ich teste seit Monaten diese Migration immer wieder. Leider kommt es hier und da immer mal wieder zu kleinen " Problemchen".
Ja es sind zwei verschiedene Forrest.
Zitat von @emeriks:
Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft ..... angepasst werden soll? ("fix ... membership")
Hast Du?Und bei der Benutzermigration hast Du auch angegeben, dass die Mitgliedschaft ..... angepasst werden soll? ("fix ... membership")
Diese Einstellung steht im userAccountControl. ..... Das muss man explizit angeben.
Hast Du?
Es scheint so als er könne er das auch nicht zuordnen, da die Gruppen verschiedene SIDs haben.
Zitat von @Hendrik2586:
Es scheint so als er könne er das auch nicht zuordnen, da die Gruppen verschiedene SIDs haben.
Welche Gruppen?Es scheint so als er könne er das auch nicht zuordnen, da die Gruppen verschiedene SIDs haben.
Die Standard-Gruppen bekommt man mit dem "fix ... membership".
Alle anderen muss man vorher migriert haben, ggf. mit sidHistory. sidHistory ist sinnvoll, wenn man will, dass vorhandene NTFS-Berechtigungen u.ä. weiterhin funktionieren. Manuell erstellte Gruppen in der Zieldomäne werden nicht berücksichtigt.
Warum machst Du diese Aktion überhaupt? Warum in eine neue Domäne migrieren?
Zitat von @emeriks:
Die Standard-Gruppen bekommt man mit dem "fix ... membership".
Alle anderen muss man vorher migriert haben, ggf. mit sidHistory. sidHistory ist sinnvoll, wenn man will, dass vorhandene NTFS-Berechtigungen u.ä. weiterhin funktionieren. Manuell erstellte Gruppen in der Zieldomäne werden nicht berücksichtigt.
Warum machst Du diese Aktion überhaupt? Warum in eine neue Domäne migrieren?
Zitat von @Hendrik2586:
Es scheint so als er könne er das auch nicht zuordnen, da die Gruppen verschiedene SIDs haben.
Welche Gruppen?Es scheint so als er könne er das auch nicht zuordnen, da die Gruppen verschiedene SIDs haben.
Die Standard-Gruppen bekommt man mit dem "fix ... membership".
Alle anderen muss man vorher migriert haben, ggf. mit sidHistory. sidHistory ist sinnvoll, wenn man will, dass vorhandene NTFS-Berechtigungen u.ä. weiterhin funktionieren. Manuell erstellte Gruppen in der Zieldomäne werden nicht berücksichtigt.
Warum machst Du diese Aktion überhaupt? Warum in eine neue Domäne migrieren?
Die SIDs sind nicht das Problem merke ich, da die Nutzer eh kaum berechtigungen haben. bzw. gar keine.
Es ist so das wir zwei Standorte in ein AD gepackt haben. So nun bin ich gerade dabei den einen Standowrt zu exportieren und die wollen das so restriktiv haben wie zuvor. Heißt die Nutzer sollen dort im AD nur als Domänen-Gäste stehen ( also Gäste im Buildin). So das habe ich soweit nun auch hinbekommen. Nun stehe ich aber vor dem Problem das ich die Nutzer alle raus haben will aus der Grupper der Domänen-Benutzer. Dies scheint aber wieder schwieriger zu sein da diese ja alles als Primay Group hinterlegt haben und somit nicht entfernt werden können.
Mit dieser OU wird ein Sync nach extern gemacht mit einem DOMHEAD.
Am Rande. Ich will nicht motzen. Aber: Wer 25.000 Benutzerkonten migrieren will/soll, müsste es doch auf dem Kasten haben?
Ja, dann muss man eben die primaryGroupID ändern. (bzw. gleich beim Migrieren mit ADMT einchließen)
siehe z.B. hier: http://www.windows-infrastructure.de/change-users-primary-group-powersh ...
Ja, dann muss man eben die primaryGroupID ändern. (bzw. gleich beim Migrieren mit ADMT einchließen)
- Benutzer der Gäste-Gruppe hinzufügen.
- primaryGroupID auf 501 ändern
- Benutzer aus der Benutzer-Gruppe entfernen
siehe z.B. hier: http://www.windows-infrastructure.de/change-users-primary-group-powersh ...
Zitat von @emeriks:
Am Rande. Ich will nicht motzen. Aber: Wer 25.000 Benutzerkonten migrieren will/soll, müsste es doch auf dem Kasten haben?
Am Rande. Ich will nicht motzen. Aber: Wer 25.000 Benutzerkonten migrieren will/soll, müsste es doch auf dem Kasten haben?
Nein müsste er nicht wenn es sein 1. mal ist und kein weiterer mit Windows umgehen kann.
Ja, dann muss man eben die primaryGroupID ändern. (bzw. gleich beim Migrieren mit ADMT einchließen)
Das funktioniert leider nicht-
- Benutzer der Gäste-Gruppe hinzufügen.
- primaryGroupID auf 501 ändern
- Benutzer aus der Benutzer-Gruppe entfernen
siehe z.B. hier: http://www.windows-infrastructure.de/change-users-primary-group-powersh ...
diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
Zitat von @Hendrik2586:
Nein müsste er nicht wenn es sein 1. mal ist und kein weiterer mit Windows umgehen kann.
Putzt Dir mal die Nase! Entweder größenwahnsinnig oder hochnäsig. Oder einfach grob fahrlässig. Das kann man jetzt nur vermuten. Vielleicht sind es ja auch nur 25.000 Dummykonten .....Nein müsste er nicht wenn es sein 1. mal ist und kein weiterer mit Windows umgehen kann.
Ja, dann muss man eben die primaryGroupID ändern. (bzw. gleich beim Migrieren mit ADMT einchließen)
Das funktioniert leider nicht-diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.Tu Dir selbst einen Gefallen und rufe das Systenhaus Eures Vertrauens an.
Zitat von @emeriks:
Der Geht-Nicht-Fehler wieder ... Da hast Du aber echt Pech!
Tu Dir selbst einen Gefallen und rufe das Systenhaus Eures Vertrauens an.
Zitat von @Hendrik2586:
Nein müsste er nicht wenn es sein 1. mal ist und kein weiterer mit Windows umgehen kann.
Putzt Dir mal die Nase! Entweder größenwahnsinnig oder hochnäsig. Oder einfach grob fahrlässig. Das kann man jetzt nur vermuten. Vielleicht sind es ja auch nur 25.000 Dummykonten .....Nein müsste er nicht wenn es sein 1. mal ist und kein weiterer mit Windows umgehen kann.
Ja, dann muss man eben die primaryGroupID ändern. (bzw. gleich beim Migrieren mit ADMT einchließen)
Das funktioniert leider nicht-diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.Tu Dir selbst einen Gefallen und rufe das Systenhaus Eures Vertrauens an.
Ich merke schon, mit dir brauche ich mich nicht darüber zu unterhalten. Ich weiß nicht was ich dir getan habe, aber es muss extrem schlimm für dich gewesen sein.
Ich suche hier nach hilfreichen Tips und rede vernünftig mit dir und du kommst mir mit dem Satz:" Ruf das Systemhaus eures Vertrauens an"! Ganz ehrlich, dann suche ich lieber nen Monat nach der Antwort bevor ich mir so pampig kommen lasse.
Zitat von @Hendrik2586:
Ich suche hier nach hilfreichen Tips und rede vernünftig mit dir und du kommst mir mit dem Satz:" Ruf das Systemhaus eures Vertrauens an"! Ganz ehrlich, dann suche ich lieber nen Monat nach der Antwort bevor ich mir so pampig kommen lasse.
Ich rede auch vernünftig mit Dir. Sonst würde ich mir gar nicht die Mühe machen.Ich suche hier nach hilfreichen Tips und rede vernünftig mit dir und du kommst mir mit dem Satz:" Ruf das Systemhaus eures Vertrauens an"! Ganz ehrlich, dann suche ich lieber nen Monat nach der Antwort bevor ich mir so pampig kommen lasse.
Ich glaube, in meinem Alter und mit meiner Erfahrung kann ich mir eine solche Bemerkung locker erlauben. 25.000 Benutzer sind kein Pappenstiel. Und ich würde für eine Migration einer solchen Umgebung nur jemanden ranlassen, der es aus dem ff beherrscht. Bei mir sind schon ganz andere wegen solcher Sachen durchgefallen. Da sind Mitarbeiter richtig großer Dienstleister dabei.
Und weil Du es bist habe ich mir eben die Mühe gemacht und das nachgestellt.
Fazit:
Fazit:
- primäre Mitgliedschaft in Domänen-Gäste verwirft er. Da wird Domänen-Benutzer draus. Das ist ein Bug oder "Feature", keine Ahnung. Kann man aber ganz einfach per Powershell korrigieren
- userAccountControl kann man einschließen. Das wird dann 1:1 übernommen.
Zitat von @Hendrik2586:
diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
Get-aduser -unlimited | set-aduser ? ?
Mit freundlichen Grüßen
Zitat von @emeriks:
Und weil Du es bist habe ich mir eben die Mühe gemacht und das nachgestellt.
Fazit:
Und weil Du es bist habe ich mir eben die Mühe gemacht und das nachgestellt.
Fazit:
- primäre Mitgliedschaft in Domänen-Gäste verwirft er. Da wird Domänen-Benutzer draus. Das ist ein Bug oder "Feature", keine Ahnung. Kann man aber ganz einfach per Powershell korrigieren
- userAccountControl kann man einschließen. Das wird dann 1:1 übernommen.
Nope ich habe mit dem PES gearbeitet und alle Kennwörter mitgenommen nachdem ich den PS key erstellt habe. Die Accounts habe ich gestern nocheinmal migriert und das enabled mit den Optionen die vorher gesetzt wurden .
Für das setzen der Primary Group bauen wir nun gerade ein PS Skript. Dies machen wir in einer kleinen Gemeinschaftsarbeit, da mir hier in der Hinsicht auch niemand attock eine Antwort geben konnte.
Aber auch das kann man ganz einfach mit Powershell setzen. Oder sogar mit der MMC für alle Benutzer einer OU auf einmal. Und sowas weiß ein 25.000-User-Admin i.A.
Zu dieser Thematik muss ich dir aber eines sagen, jeder hat mal klein angefangen und auch ich habe in einer Testumgebung zuvor geübt und probiert, es gibt aber nunmal immer wieder Dinge die einfach dazwischen gretschen die in den Tests nichts passiert sind. (z.B der Bug mit der Gruppe Domänengäste)
Sorry das ich gestern ro gereizt reagiert habe, aber bei einigen Dingen werde ich extrem sauer und ich war eh schon geladen. Wenn ich z.B jemandem Helfe dann mache ich das mit sehr, sehr viel Geduld gerade wenn es um etwas umfangreichere Themen gibt.
Man sollte aber niemal sagen, das man aufgrund seines angeeigneten Wissen und Berufsangehörigkeit Überheblichkeit raushängen lassen kann, das sorgt für ganz böse Stimmung innhalb es Teams/Unternehmens.
LG.
Zitat von @7Gizmo7:
Get-aduser -unlimited | set-aduser ? ?
Mit freundlichen Grüßen
#Zitat von @Hendrik2586:
diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
diese Anleitung macht das nur für einen Nutzer. Wenn ich es abwandele macht das Script nicht mit da die Maximal Grenze überschritten wurde.
Get-aduser -unlimited | set-aduser ? ?
Mit freundlichen Grüßen
Unlimited? Das wäre noch ne Möglichkeit.
Danke dir.
Du hast es Dir auchselbst zuzuschreiben.
Zitat von @Hendrik2586:
Der Geht-Nicht-Fehler wieder ... Da hast Du aber echt Pech!
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.
Wenn man solche kleinen Hinweise nicht versteht oder ignoriert, dann braucht man sich nicht zu wundern, wenn die Geduld irgendwann aufgebraucht ist. Du suchst hier doch keine Mutter, oder?Der Geht-Nicht-Fehler wieder ... Da hast Du aber echt Pech!
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.
Zitat von @emeriks:
Du hast es Dir auchselbst zuzuschreiben.
Du hast es Dir auchselbst zuzuschreiben.
Zitat von @Hendrik2586:
Der Geht-Nicht-Fehler wieder ... Da hast Du aber echt Pech!
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.
Wenn man solche kleinen Hinweise nicht versteht oder ignoriert, dann braucht man sich nicht zu wundern, wenn die Geduld irgendwann aufgebraucht ist. Du suchst hier doch keine Mutter, oder?Der Geht-Nicht-Fehler wieder ... Da hast Du aber echt Pech!
Hm, ja ja. Der uns unbekannt Befehl .... ja, ja.
Auf solche Sticheleinen gehe ich grundsätzlich nicht ein denn sie sind unnötig. Sowas kann man mit kleinen Kindern machen wenn man meint das es irgendwas bringt.
Nein eine Mutter brauche ich nicht, davon hab ich mir in meiner Sturm -und Drangzeit genug gesucht. ;) Danke aber trotzdem der Nachfrage.
Jedenfalls hättest Du dann solche Hinweise wie von @7Gizmo7 schon viel eher bekommen können.
Servus. Mit der Nase draufstoß....
wenn Du Deine Befehle für so geheim hälst, und auch die exakten Fehlermeldungen dazu nicht postest, dann ist es mehr Rätselraten als sonstwas.
Grüße, Henere
wenn Du Deine Befehle für so geheim hälst, und auch die exakten Fehlermeldungen dazu nicht postest, dann ist es mehr Rätselraten als sonstwas.
Grüße, Henere
