Zwei Firmen in einer Active Directory trennen

Servus,


die Anforderung stellen doch die produktiven Einheiten. Die EDV führt sie lediglich aus.
Die gestellte Anforderung, die in meinen Augen völlig korrekt ist, kann ich sehr gut nachvollziehen.


Wie es (mittlerweile) zwei verschiedene Unternehmen sind, sollten diese auch jeweils ihre
eigene Domäne/Gesamtstruktur erhalten. Eine "Sicherheitsgrenze" stellt NICHT die Domäne,
sondern Gesamtstruktur dar.


Dann migriere dieses Unternehmen in ihre eigene Domäne/Gesamtstruktur.


Nein, keineswegs. Migriere das Unternehmen in eine neue Domäne mit ADMT, dann hast du klare Verhältnisse.


Kommt darauf an, als was du "sehr hoch" definierst. Du könntest mit ADMT migrieren, da lässt es
sich "recht einfach" damit migrieren. Natürlich gibt es immer wieder mal Stolperfallen, doch diese
bekommt man schnell in den Griff.


Wenn es notwendig ist, dann ja.


Genau.


Nein, nicht nötig. Beide Punkte erledigt das ADMT für dich. Du müsstest dann nur noch das Login-Skript anpassen.


Viele Grüße
Yusuf Dikmenoglu

Hallo Kachte,

wenn die Administration bei einer Stelle bleibt macht es nicht viel Sinn die Firmen zu trennen. Sollte genau dieses abgekoppelt werden, also eine eigene Administration der Systeme (eigene IT für Firma A und eigene IT für Firma B) integriert werden, so sollte man auch jeweils eine eigene Domäne und somit auch eigene Serversysteme aufbauen.
Das währe meiner Meinung nach konsequent. (VMWARE lässt grüßen)

Alles andere macht man in einer Domäne und trennt die Firmen in OU's, also für Firma A eine OU und für Firma B eine OU.
Genauso wie du es bereits angedacht hast. Natürlich kann man hier auch einen Forest mit zwei Domänen konfigurieren, allerdings müssen dann auch wieder Migrationen berücksichtigt werden.

Keine Ahnung wie das Rechtlich aussieht, ich habe da mal von Einschränkungen gehört, also das Firmen auch "IT technisch" getrennt werden müssen.

In letzter Konsquenz bestimmt aber in der Regel der Chef, vll kann man dir da mal mehr Background zur Verfügung stellen.

Gruß

Sascha

In der Theorie mag das stimmen - praktisch sieht es da schon anders aus.
Ich hab die ganze Aktion die dem OP bevor steht über Neujahr praktiziert. Und ich kann nur sagen, dass es reichlich Arbeit war.
Zuerst müssen ja mal die neuen Domänen geschaffen werden mit allem was dazu gehört. Danach die User und Clients per ADMT umziehen. Und da hakt es dann auch und bringt reichlich Handarbeit mit sich. Das fängt bei Gruppen an, in denen sich User aus beiden zukünftigen Domänen befinden. Da kann das ADMT nämlich logischerweise nicht entscheiden wohin diese Gruppe soll.
Dann kommen die nächsten Probleme mit den Clients. Bei mir hat der automatische Reboot, den das ADMT eigentlich auslösen soll nicht ein einziges Mal funktioniert. Und damit kamen die Clients dann auch nicht von selbst in die neue Domäne. Also war Handarbeit angesagt.
Und zum guten Schluss haben die User ja auch noch Postfächer die auch noch angepackt werden müssen.
Fazit: Automatische Tools sind prima, wenn sie das tun, was sie tun sollen. Einmal angefangen gibt es aber kein zurück mehr...

Manuel

Das eine Migration nicht mit einem Mausklick durchgeführt ist, ist hoffentlich jedem klar.



Ohh... man muss bei einer Migration mehr tun als zweimal auf die Maus zu klicken?
Wem der Begriff --> Migration <-- nicht klar ist und nicht weiß, was alles dahinter steckt,
dann...


So fängt eine Migration die Erfolg haben soll auch an.



Nicht nur die Clients, auch die Memberserver können mit ADMT migriert werden.


Das ist pauschal falsch! Wo es meistens hakt, ist bei der Migration der Computerkonten.
Es kommt auf den "Zustand" der Maschinen an. Aber das es da *immer* Probleme gäbe,
ist einfach nicht korrekt.

Bei meinen etlichen Migrationen im Enterprise-Bereich (ab 1.000 Clients) habe ich alle Probleme noch in den Griff bekommen und die Handarbeit war eher gering.



Diese Anforderungen müssen geklärt werden und nochmals,
wer im "glauben" ist das eine Migration mit einem Mausklick erledigt ist, der ist falsch gewickelt.
Da kommt noch einiges an Nacharbeit hinzu. Aber zumindest lässt sich der Erfolg mit einem Werkzeug
wie ADMT, die große und schwere Aufgabe einer Migration, schon um einiges erhöhen. Man kann natürlich
auch auf kommerzielle Tools setzen, wie z.B. dem Quest Migration Manager (QMM), der einiges mehr kann.



Tja... dann ist bei dir etwas ganz schief gelaufen. Bei den Erfahrungen die ich mit ADMT schon gemacht habe
(und das bei über 12 jähriger Berufspraxis), kommt es zwischen 5 und 10% vor, dass Clients Probleme machen. Aber die meisten ließen sich ohne Probleme migrieren.



Dann war die Vorarbeit nicht so wie sie sein sollte.



Dann sollte evtl. ein anderes Werkzeug gewählt werden, wie z.B. QMM für AD und Exchange.



Das tun sie auch. Aber der Einsatz und Erfolg aller Werkzeuge, hängt von der gegebenen Umgebung ab.



Dann hast du kein Rollback-Plan erstellt und auch mit ADMT, funktioniert ein "zurück".


Viele Grüße
Yusuf Dikmenoglu

Und selbst wenn: Verschieben wäre nicht gegangen, da das nächste mögliche Zeitfenster im Jahreswechsel 09/10 gelegen hätte. Und jetzt mach das mal den hochbezahlten Herren klar denen du alleine bei dem Kürzel ADMT jedes einzelne Wort erklären musst. Mithin war da auch keine Zeit für Experimente. Es musste schlicht der Weg gewählt werden der zum Erfolg führt - auch wenn es vielleicht nicht der angenehmste war (in Bezug auf die Handarbeit).
Im Übrigen haben wir bei der Aktion in einem das gemacht, was "normale" Menschen in 2-3 Parts machen. Virtualisierungsumgebung aufgebaut, alle Server virtualisiert, alles auf w2k8 bzw. e2k7 aktualisiert, aus einer Domäne vier Domänen gezaubert und noch ein paar Kleinigkeiten.

Das hört sich jetzt aber anders an, als in deiner vorherigen Antwort.
Du hattest eher ein "organisatorisches" Problem, denn technisch, ist das selbstverständlich möglich.


Gruß, Yusuf Dikmenoglu

Hallo,

die Trennung in zwei Domänen (bzw Forests) macht doch nur sinn, wenn du ganze auch Netztechnisch trennen kannst. Ist das gegeben? Gibt es keine gemeinsam genutzten Resourcen?

Eine Trennung auf OU-Ebene ist durchaus möglich. Auf den OUs kann man entsprechend Rechte vergeben, dass nur die Admins der jeweils eigenen Firma dort administrieren können. Und auch etliche andere Berechtigungen (Zugriff auf Shares, Nutzung von Printservern,...) lassen sich dann auf Gruppenebene so einstellen, dass nur die eigene Firma nutzen darf. Einerseits macht das bei der Administration aber immer zusätzlichen Aufwand (und man vergißt dann mal, eine Firma auszuschließen, und mit Domainadmin-Accounts kann man auch nicht mehr arbeiten), andereseits sind auch Grenzen gesetzt. Eine gemeinsame Nutzung einer Exchange-Organisation, ohne dass die einen die Adressen der anderen sehen können beispielsweise ist eher schwierig.

Kläre erstmal, ob den Verantwortlichen klar ist, dass dann auch wirklich sehr viele Resourcen getrennt beschafft/betrieben werden müssen, und ob das wirklich das ist, was man will.

Gruß

Filipp