Probleme mit ADMT Gruppenmigration

[MuMichel 10]

Hallo zusammen;

Wir sind gerade dabei aus einer Domäne in eine neue zu migrieren.

Das Problem ist, das wir aus einer grossen Domäne in einen Forest mit mehreren Standortdomänen migrieren.

Benutzer--> ken Problem

Computer--> kein Problem

Problem ist, dass wir gemeinsame Gruppen an unterschiedlichen Standorten nutzen und ich die Gruppen immer nur in eine Domäne migrieren kann.

Gibt es eine Möglichkeit eine Gruppe incl. SID in mehrere in einem gemeinsamen Forest befindlichen Domänen zu migrieren??

 

Vielen Dank schon mal

Michael

bearbeitet 10. Dezember 2010 von MuMichel

[NilsK 2.786]

Moin,

 

rein technisch betrachtet, könntest du einfach mehrere unabhängige Migrationen derselben Quellgruppen in mehrere Zieldomänen ausführen, auch mit SIDHistory.

 

Die viel spannendere Frage ist, ob das sinnvoll wäre, und da habe ich spontan so meine Zweifel, aber um das konkret zu sagen, müsste man sich so weit mit der konkreten Umgebung beschäftigen, dass es in einem Forum nicht mehr sinnvoll zu leisten ist.

 

Gruß, Nils

[dmetzger 10]

Eine SID enthlt u.a. einen Domain Identifier. Mir ist nicht klar, was Du erreichen willst.

 

Security Identifier Structure

[MuMichel 10]

Hallo;

Recht einfach..

z.B. ich hab vorher eine Domäne mit 3 Standorten.

Abteilungen sind überall gleich.

Zusammenarbeit ist Standortübergreifend. Aber Fileserver stehen verteilt an jedem Standort

Also gibt es eine DL Gruppe die Abteilung 123 heisst, und streng nach MS eine GG Gruppe die Abteilung 123 heisst in der sich die User befinden.

 

Nun kommt ein schlauer Mensch auf die Idee, wir machen alles anders...

 

Also gibt es einen grossen Forest mit u.A. den 3 Standorten als je eine Domäne.

Nun muss ich die Gruppen der Abteilung 123 in alle 3 Standorte migrieren damit die Zugriffe jetzt Domänenübergreifend weiter funktionieren.

ADMT 3.2 meldet aber ; "Die gibts schon in Domäne trallala" und migriert mir die Gruppe nicht (auch nicht von einem anderen ADMT-Server aus).

Das Umbenennen der Gruppen funktioniert auch nich, da die SID scheinbar abgefragt wird.

Ich bin immer noch ratlos...

 

Gruß

Michael

[NilsK 2.786]

Moin,

 

abgesehen davon, dass das von Microsoft vorgesehene Gruppenkonzept etwas anders funktioniert ...

 

... würde ich als Workaround die DL-Gruppen einmalig in den Zielforest migrieren und dann in Universal Groups umwandeln. Mittelfristig solltet ihr dann die Berechtigungen auf Basis neuer Gruppen (und des richtig angewandten A-G-DL-P-Konzepts) neu zuweisen und die SIDHistory entfernen.

 

Vorher testen versteht sich von selbst.

 

Gruß, Nils

[dmetzger 10]

Also gibt es einen grossen Forest mit u.A. den 3 Standorten als je eine Domäne.

 

Wenn ich fragen darf: Aus welchem Grund?

[MuMichel 10]

Hallo Nils;

 

Accounts go in Global Groups nested in Domain Local Groups that are granted Permissions...

 

Genau So meinte ich..

 

Benutzer in Global; die in Lokal, die hat Zugriffsrechte. Passt doch ;-)

Aber die Migration und dann in UG Umwandlung löst ja nicht mein Problem..

Auch dann hab ich die Gruppe nur in einer Domäne liegen. Funktioniert zwar ist aber so nicht wünschenswert sondern nur als Notlösung zu betrachten.

 

Und warum.... frag ich mich auch... aber auf mich hört ja keiner :-(

 

Gruß

Michael

[NilsK 2.786]

Moin,

 

Accounts go in Global Groups nested in Domain Local Groups that are granted Permissions...

 

ja, eben.

 

Benutzer in Global; die in Lokal, die hat Zugriffsrechte. Passt doch ;-)

 

Es ist aber unsinnig, die Globalen Gruppen mit Domänenlokalen Gruppen zu verdoppeln. Mit den DL-Gruppen legst du Berechtigungsstufen bzw. Zugriffsrollen fest. Sonst hat das ganze ja keinen Sinn.

 

Aber die Migration und dann in UG Umwandlung löst ja nicht mein Problem..

 

Doch.

 

Funktioniert zwar ist aber so nicht wünschenswert sondern nur als Notlösung zu betrachten.

 

Da die ganze SIDHistory-Migration nur eine Notlösung für eine Übergangszeit ist, sehe ich grad dein Problem nicht.

 

Gruß, Nils

[dmetzger 10]

Da die ganze SIDHistory-Migration nur eine Notlösung für eine Übergangszeit ist, sehe ich grad dein Problem nicht.

 

@MuMichel:

Du kannst die SIDHistory migrieren, nicht aber die SID. Werden Objekte in eine andere Domäne migrieren, erhalten sie eine neue SID:

 

SID-History Attribute (Windows)

 

Mich würde es noch immer interessieren, aus welchem Grund man eine einfache Infrastruktur in eine komplexe überführt. Wir haben gelernt: Alles Geniale ist einfach. Es muss also gute Beweggründe geben, davon abzuweichen, nur hast Du sie bisher nicht genannt.

[MuMichel 10]

Gut dann mal ein paar Hintergründe:

Firma x mit grosser einfacher und gut funktionierender Domäne fusioniert unter neuem Namen Z mit Firma Y (auch mit vorhandener Domäne)

Zusammen ca. 30 Standorte rund um die Welt verteilt. Neue Domäne wird von extem schlauen nicht ITlern in der Struktur vorgegeben und steht nicht zur Diskussion.(Iss halt so...).

Struktur sieht vor: Grosse leere Domäne darunter aufgeteilt in 4Wirtschaftsräume: EMEA; NORAM; LAC; APAC...darunter die jeweiligen Standorte einsortiert als eigenständige Subdomäne.

Ist bei allen Standorten die vorher alles an einem Ort hatten kein Problem.

Nur bei Firma X die eine Domäne, eine Admnistration, eine Gruppen- und Berechtigungsstruktur aber mehrere Standorte hatte taucht dieses Problem auf.

Um das AD übersichtlicher zu gestalten wurden vorher die DL-Gruppen und G-Gruppen überall gleichnamig benutzt um die User auf die an den Verschieden Standorten zu berechtigen.z.B.

An jedem Standort gab es eine Abteilung123. An jedem Standort einen eigenen Filer mit dem Verzeichnis Projektabwicklung_Abteilung123.

Im AD gab es nur eine DL Gruppe DL_Projektabwicklung_Abteilung123 und in der eine GG_Projektabwicklung_Abteilung123. Darin wurden dann die User reingepackt. Damit hatte der User123 an jedem Standort Zugriff auf die Verzeichnisse. Durch DFS hatten die User eigentlich keine Ahnung, wo das Verzeichnis physikalisch liegt. Das wurde beim Anlegen des Verzeichnisses von dem jeweiligen Chef der Abteilung entschieden.(Je nach dem, wo vorraussichtlich die meisten Daten anfallen..))

Also (auch wenn es auf den ersten Blick keinen Sinn ergibt..) brauch ich an den nun aufgeteilten Standorten die DL und die GG Gruppen gleich.

Nach und nach soll sich das natürlich ändern aber wir reden über ca. 100 TB Daten und über 1000 DL Gruppen sowie ca. 4000 User.

Die kann man nicht so einfach neu anlegen und Berechtigen!

Im Moment scheint mir die beste Lösung zu sein, alle Gruppen in eine der neuen Domänen zu migrieren, alle Benutzer auch dahin; dann die Benutzer weiter auf die jeweiligen Standorte weiter zu migrieren. Nur so scheint es zu funktionieren.

Naja, hab ja noch eine Woche Zeit zum testen...:-(

Über Sinn oder Unsinn zu diskutieren hat keinen Wert und bringt mich leider auch nicht weiter.

Danke an alle, die sich mit mir den Kopf zerbrechen!

Michael

[NilsK 2.786]

Moin,

 

bei der gegebenen Komplexität und dem allgemeinen bzw. grundlegenden Bereich der Fragen ist ein Forum nicht mehr die geeignete Diskussionsplattform. Das ist eine Sache für intensives Consulting.

 

Ich klinke mich hier aus.

 

Gruß, Nils

[dmetzger 10]

Neue Domäne wird von extem schlauen nicht ITlern in der Struktur vorgegeben und steht nicht zur Diskussion.(Iss halt so...).

 

Das ist halt Pech und wird in Zukunft irgendwann als Altlast und Problem erkannt werden. Aber dann ist der schlaue Kopf nicht mehr da oder alle anderen sind schuld.

 

Grosse leere Domäne darunter aufgeteilt in 4Wirtschaftsräume: EMEA; NORAM; LAC; APAC...darunter die jeweiligen Standorte einsortiert als eigenständige Subdomäne.

 

Also: subdomäne.emea.firma.com, und das rund 30 Mal? :confused: Wenn ja, weiss Euer schlauer Kopf etwas, was wir nicht wissen und MS wahrscheinlich ebenfalls nicht.

 

Naja, hab ja noch eine Woche Zeit zum testen..

 

Ihr sollt diese Migration in einer Woche durchziehen? :shock:

 

Insgesamt meine ich, dass dieses Szenario den Rahmen womöglich übersteigt, den dieses Forum an Hilfestellung leisten kann oder soll (persönlice Meinung!). Eine solche Aufgabe sollte durch Migrationsspezialisten vor Ort und während ausreichender Zeit begleitet werden.

 

Edit: Nils ist unabhängig von mir zum gleichen Schluss gekommen, während ich hier diesen Beitrag geschrieben habe. Das weist darauf hin, dass diese Einschätzung möglicherweise zutrifft. (Auch weil wir solche komplexen Szenarien als bezahlte Spezialisten begleiten und ich für meinen Teil es gegenüber Auftraggebern kaum begründen könnte, dass ich dieses spezialisierte Wissen an anderer Stelle verschenke.)

[MuMichel 10]

Naja, ist ja nicht meine erste Migration, nur das Problem ist neu.

Rest der Welt haben wir ja schon fertig.

Hängt halt nur an dem Problem dass ich die Gruppen nicht in mehrere Domänen migiríeren kann und ich dachte, dass ich da irgendwo einen kleinen Fehler mache und mich festbeisse.

Also: subdomäne.emea.firma.com, und das rund 30 Mal? Wenn ja, weiss Euer schlauer Kopf etwas, was wir nicht wissen und MS wahrscheinlich ebenfalls nicht.

 

 

Übrigens kam die grobe Struktur direkt aus München von MS zu unseren schlauen Köpfen....

Im Moment denkt ich darüber nach, eine Domäne zur Recourcendomäne zu erklären; alle Filer und Gruppen rein und alles wird gut. (So hat mir das übrigens MS beigebracht)

 

Ich schreib Euch auf jeden Fall, wie ich es gelöst habe.

 

Danke für Euere Hilfe und schönes Wochenende!!

 

Michael

[dmetzger 10]

Übrigens kam die grobe Struktur direkt aus München von MS zu unseren schlauen Köpfen....

 

Ist ja interessant, eine richtige Pointe! :D

 

Meines Wissens hat MS selbst eine einfachere Struktur ohne eigene Domäne pro Standort, sondern bloss regional, wobei Redmond eine eigene Region ist. :) Deshalb erstaunt mich, dass München eine solche AD-Struktur empfiehlt, auch weil es ausreichend viele publizierte und interne AD Design Guides von MS gibt, in denen das Gegenteil nachzulesen ist.

[MuMichel 10]

Ist ja interessant, eine richtige Pointe!

Ich war ja nicht dabei und kenn die Vorgaben nicht...