Daim

Servus, - es muss das Recht DELETE CHILD (DC) in dem Quell-Container gesetzt werden. - es muss das Recht WRITE PROPERTIES (WP) für die beiden Eigenschaften RDN sowie CN auf dem Quell-Container gesetzt werden. - es muss das Recht CREATE CHILD (CC) auf dem Ziel-Container gesetzt werden. Du solltest das ganze mit DSACLS durchführen. Schau dir dazu in diesem Artikel unterhalb von DSACLS den Befehl an: Yusuf`s Directory - Blog - Objektdelegierungen einrichten

Servus, nein, nicht "seltsamerweise", denn das ist unter Windows Server 2008 "by Design" so. Dort wird eine Delegierung nun automatisch mit eingerichtet. Es ist ein neues Feature.

Na was ein Glück. ;)

Genau so ist es. Ohne eine Vertrauensstellung kann das so nicht funktionieren.

Ein globaler Katalog kann nur die Informationen EINER Gesamtstruktur in der er selbst Mitglied ist enthalten. Alle Objekte aus einer Gesamtstruktur egal aus welchen Domänen, sind im GC enthalten. Somit ist es zwangsläufig notwendig, dass alle Domänen zur gleichen Gesamtstruktur gehören und unter diesen dann automatisch eine transitive bidirektionale Vertrauensstellung besteht.

Du willst jetzt damit aber nicht den OP dazu bringen, die Domäne doch zu splitten?!

Hola, lies doch einfach hier ;) : Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC)

Sicherheit ist in der IT - IMMER - ein Thema! Ich kann mich nur wiederholen. Sobald eine Domäne gesplittet wird, MUSS eine Migration und kein Pfusch betrieben werden! Ich kann es dir nur ans Herz legen. Sobald ein Unternehmen sich trennt, erstelle für die eine Firma eine eigene Domäne, sonst könnte das später böse enden!

Servus, lies dir diesen und die weiterführenden Artikel durch: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Ein für Windows 2008 supportetes ADMT sollte Juni/Juli erscheinen. Aber trotzdem würde ich es mit dem 3.0 trotzdem versuchen. Zu Beta Zeiten habe ich erfolgreich auch unter 2008 mit dem ADMT 3.0 Migrationen durchgeführt. Aber wie gesagt, ADMT 3.1 müsste jeden Tag erscheinen. Korrekt. Dann bleiben da noch die Dateien die auf dem Desktop abgelegt wurden oder Eigene Dateien usw... Weil im alten Profil evtl. noch Daten sind? Wie dem auch sei, ich denke wir haben nun alles durchdiskutiert und DU musst dir den Weg zusammenstellen.

Wenn du die Suchmaschine deines Vertrauen aufsuchst und ASR eingibst, wirst du jede Menge dazu finden. Leider habe ich gerade keinen Link parat. Aber wenn du z.B. eine Abteilung zusammenfasst, könnten evtl. 20 Benutzer in einer OU sein und wenn diese gelöscht wird, ist das auch mehr als ärgerlich. Was ich dir damit veranschaulichen wollte ist lediglich, dass du um das erstellen einer System State Sicherung nicht herum kommst. Na mit dem ADMT kannst du doch auswählen, welche Objekte (Benutzer- sowie Computerkonten) migriert werden sollen und welche nicht. Leichen brauchst du natürlich nicht "mitnehmen". Vieles wird klarer, wenn du es mal in einer Testumgebung testest. Vorbildlich. Scheinbar habt ihr aber nicht soo viel zu tun, da du weiterhin auf das neu anlegen der Benutzer beharrst. Ich sage dir, wenn du mit ADMT migrierst, sparst du dir eine Menge Arbeit und dabei nimmst du auch keinen alten Schrott mit, den du nicht möchtest. Ich kann es dir nur empfehlen. Wenn du eine ABM-Maßnahme (Arbeitsbeschaffungsmaßnahme) daraus machen möchtest, dann nur zu. Wenn du nun in der neuen Domäne den Benutezr neu einrichtest, erhält der User ein neues Profil. Also musst du dann das alte Profil umkopieren, mit all seinen Macken. Mit ADMT hast du diese Sorgen nicht. Also wenn DU dich weiter so zierst und die Migration mit ADMT nicht durchführen möchtest, mache ich es bald für dich. ;) Natürlich, sei es lokal oder servergespeichert.

Völlig korrekt. Den Aufwand hättest du am Anfang. Aber wenn das Konzept dann mal steht, ist es einerseits die Variante die auch vom Hersteller empfohlen wird und jeden Wirtschaftsprüfer/IT-Revision stand hält. Du hast somit ein ordnungsgemäßes Bachup-Konzept. Du könntest ja mal einen fachkompetenten Dienstleister Fragen was er davon hält. Falls er dir auch zum Imaging rät, wechsele den Dienstleister. :p Sorry, aber nun halte ich mich zum Thema Imaging zurück. Zu diesem Thema ist mir jede Silbe zu schade. Wie gesagt, DU entscheidest.

Auch das wird in dem Artikel bereits in den ersten drei Sätzen beantwortet, beachte dazu die rote Schrift: Mit der ASR-Sicherung wird das System gesichert (samt System State), nicht die Daten. Diese müssen gesondert gesichert werden. Das ist mir schon bewußt, dass ein Image genau diese Verlockung hervor ruft, eben schnell nach einem Crash den gesamten Server samt Daten wiederherzustellen. Sehr viele andere Benutzer hier an Board würden dir in diesem Thema auch zustimmen. Es würde der Hinweis kommen darauf zu achten, ein Offline-Image zu erstellen. Da bist du aber bei mir fehl am Platz. Von mir hörst du so etwas nicht. Ich kann mich nur wiederholen, Imaging wird von Microsoft nicht supportet. Ende! Moment, halt, stopp. Du sprichst vom Imaging eines frisch installierten Servers und nicht eines DCs? Dann sieht das anders aus, aber auch hierbei würde ich nicht Imagen, sondern ein mit SYSPREP bearbeitetes Master Image mir einmal erstellen und dieses jederzeit verwenden. Das kommt dann auf das gleiche raus, mit einem anfänglichen Mehraufwand aber dafür supporteten Variante von Microsoft. Weil das Thema Backup nunmal eine Wissenschaft für sich ohnehin ist. Backup ist kein doing für eine Sekretärin oder den Hausmeister, sondern ein harter Job für die IT. Wirtschaftsprüfer oder eine IT-Revision würden dir bei dem Thema Imaging und "nicht supportet" des Herstellers auch gerne dazu etwas erzählen. Was DU am Ende daraus machst, bleibt dir und jedem selbst überlassen. Nein, nicht weil du Microsoft-Werkzeuge verwendest, sondern, du eine unterstützte Vorgehensweise mit einem sehr hohen Funktionserfolg einsetzt. Ist mir klar, wir diskutieren hier nur. Am Ende entscheidest du welchen Weg du gehst. Wenn du ein System irgendwann rückimagest und erhälst Wochen später eine Folgefehler und benötigst dann den Support von Microsoft, kannst du sehr schnell ohne Hilfe von Microsoft da stehen. Weil du mit einem niedrigen Aufwand, ein laufendes System (OS+AD+DNS usw.) erhälst, was eben vom Hersteller supportet wird. Du musst keinen Computernamen nach der Installation vergeben oder die IP-Informationen bzw. irgendwelche Registry-Einstellungen. Alles wird nach der ASR-Rücksicherung wiederhergestellt. ... to be continued. P.S. Hatte ich schon erwähnt, dass mich diese 4.000 Zeichengrenze nervt?

Moin, auf welche IP-Adresse zeigt der Eintrag für den DNS-Server? Hoffentlich auf einen internen DNS-Server. Stehen Fehlermeldungen im Eventlog? Evtl. aktuelle Netzwerkkartentreiber installieren.

Ich wiederhole mich gerne noch einmal, einmal mit ADMT migriert und du willst nichts anderes mehr. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauenesstellung zwischen alter und neuer Domäne benötigt. Das ADMT richtet dann ein neues Benutzerkonto in der neuen Domäne ein und fügt die SID des alten Benutzerkontos, aus der alten Domäne an das neuen Benutzerkonto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als "Ausweis" vorzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Wenn der Benutzer von einer Domäne in eine andere Domäne migriert wird, so wird seine SID nicht mitübernommen, denn der mittlere Part der SID ist die Nummer der Domäne. Bei der Benutzer-Migration mit ADMT wird jedesmal ein neues Benutzerkonto mit einer neuen SID in der Ziel-Domäne eingerichtet. Dadurch das das "neue" Benutzerkonto eine neue SID bekommen hat, bekommt das Konto nicht die gleichen Berechtigungen wie es das alte Konto hatte, auch wenn der Benuztername gleich lautet. Denn bekanntlich sind /Namen/ "Schall und Rauch" in der IT. Nie und nimmer. Was machst du denn mit den Benutzerprofilen? Dann würde ich dir empfehlen, dass mal in einer Testumgebung zu testen. Da siehst du welche Variante die wenigste Arbeit bereitet und gibst mir dann am Ende Recht. ;) Je nach Anzahl von Benutzern sowie Clients, erspart dir ADMT keine Stunden, sondern Tage an Arbeit.

Das ist zwar richtig, aber trotzdem kannst du auf eine System State Sicherung nicht verzichten. Was ist eben, wenn ein ausversehen gelöschtes Objekt oder eine Organisationseinheit (OU) mit 200 Benutzern ausversehen gelöscht wurde? Dann brauchst du entweder eine System State Sicherung oder das Zeitfenster der standortübergreifenden AD-Replikation ist so groß, dass sich diese Löschung noch nicht auf die DCs in den Standorten repliziert hat. Denn dann kannst du diese OU autoritativ kennzeichnen und wird somit nicht gelöscht. Ja, sogar hauptsächlich dafür. Denn die Missgeschicke passieren nunmal oft durch menschliches Versagen. Beim löschen EINES Benutzers magst du recht haben, wobei du trotzdem Arbeit hast mit dem Profil, was eben nciht sein müsste. Was ist aber, wenn eine ganze OU mit 200 Benutzern auf einen Schlag gelöscht wurden? Die Sicherung bezgl. des Hardwarecrashs benötigst du nicht unbedingt, dass stimmt. Es sei denn, du möchtest einen Server an einem Standort zum DC deklarieren und dabei soll der DC so schnell wie möglich startklar sein. Dann könntest du dank der System State Sicherung und der Install from Media (IFM) Funktion einen Server zum DC stufen: Yusuf`s Directory - Blog - Domänencontroller-Installation von einer Sicherung Natürlich. Ich verstehe ehrlich gesagt nicht was die ganze Diskussion hier soll. Ein Backup wird benötigt ohne wenn und aber. Punkt. Das Gefühl habe ich auch. Wenn nicht AD-lastig gearbeitet wird, sondern lediglich Benutzer sich an der Domäne authentifizieren, kannst du das Replikationsaufkommen völligst vernachlässigen. Ansonsten nämlich, benötigt die AD-Replikation eben mehr Zeit. Denn schließlich würde für die AD-Replikation auch eine 56KB Leitung ausreichen, die Replikation würde dann eben länger benötigen. Es werden ca. 4KB pro Benutzerauthentifizierung über die Leitung repliziert, bei AD-integriertem DNS. Glaube mir, wenn du einmal eine Migration und sei es bloß für fünf Benutzer mit dem ADMT durchgeführt hast, willst du nichts anderes mehr. ;) Abgesehen davon soll das ADMT 3.1 im Sommer diesen Jahres erscheinen. Aber auch mit ADMT 3.0 sollte es möglich sein: Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To ... to be continued. P.S. Diese 4.000 Zeichengrenze nervt so langsam. ;)

Je nach Anzahl der Benutzer. Wenn der eine DC mit nur einer 1 Ghz CPU arbeitet, aber 2.000 Benutzer am Hauptstandort wären, dann würde ein zweiter DC in der Zentrale Sinn machen. Sind es bloß 400 User, dann reicht ein DC ALLEINE für die Benutzerauthentifizierung. Existieren aber noch weitere Applikationen die vom AD abhängig sind, wie z.B. Exchange etc. oder es wird AD-lastig gearbeitet, dann gilt es dies genauer zu prüfen.

Zuerst vorneweg, ich gehe nur noch auf deine Fragen ein, da wir ansonsten bis zum nächsten Jahrhundert philosophieren. Danke für dein Verständnis. Natürlich gibt es eine Alternative, nämlich die, die jeder Softwarehersteller für zum sichern seiner Systeme empfiehlt sowie SUPPORTET! Diese Alternative stellt evtl. für dich keine Alternative dar, ändert trotzdem nichts an der Tatsache, dass z.B. das Imagen von Datenbanksystem basierenden Systemen aus dem Hause Microsoft mit dieser Sicherungsmethode nicht supportet wird. Bei einem DC z.B. könnte man als Sicherungsmethode die ASR-Sicherung wählen. Sorry, aber dann hast du den Artikel nicht im geringsten verstanden. Lies dir den Artikel evtl. nochmals durch und frage ggf. was du nicht verstehst. Aber der Artikel ist mit allen Ausführung 100% korrekt. Ich persönlich halte von Imaging eines DCs nicht viel. Fakt ist aber, egal ob du online oder offline einen DC imagest, es wird von Microsoft nicht supportet. Wie gesagt, es führen viele Wege nach Rom, gerade in der IT-Welt. Prinzipiell zwar korrekt, aber wie gesagt, eine ASR-Sicherung wäre z.B. eine Alternative. Aber was beim Thema Imaging unbedingt beachtet werden sollte, ist das Master-Image zu anonymisieren. Dieses macht man, in dem man SYSPREP anwendet. Wenn es nur um das wiederherstellen eines DCs geht, dann ist das die einfachste Variante. Wenn aber ein Objekt autoritativ wiederhergestellt werden soll, so ist eine aktuelle SYSTEM STATE Sicherung Pflicht. Und idealerweise wären das unter Windows Server 2008 - RODCs. Das ist eine Möglichkeit, aber denke an SYSPREP (und an ASR). Das ist dann der Fall, wenn in den Standorten beschreibbare und keine RODCs stehen. Oder man holt sich eine aktuelle System State Sicherung die natürlich ausser Haus aufbewahrt wird und spielt diese dann zurück. Aber ein solches Disaster Recovery Konzept muss sich jedes Unternehmen erarbeiten und erstellen. Exakto Mundo. ... to be continued.

Genau so würde ich das interpretieren, denn alles andere würde keinen Sinn ergeben. Der von mir zitierte Satz aus dem Artikel zeigt es deutlich, wobei in der Ausführung das Wort "können" verwendet wird: dabei müsste es m.E. "..müssen Sie.." lauten. Aber wie gesagt, diese Seite existiert genau so seit der Beta des Windows Server 2008. Es kann sehr gut sein, dass die Seite noch aktualisiert wird. Der Vollständigkeitshalber noch dieser Link ;) : Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC)

Der Amerikaner würde jetzt sagen: You are welcome. ;)

Aber selbstverständlich. Nur das ein Recoverykonzept ohnehin in jedem Unternehmen existieren müsste, nicht nur wegen einer Änderung. ;) Aber wenn man wegen einer Änderung sich dann mal ein Recoverykonzept erarbeitet, umso besser. Wer will das schon. Korrekt.

OK. Na dann testet es doch erstmal durch. Auch wenn man es durch die Rücksicherung rückgängig machen kann, sollte es vorher komplett durchgetestet, bewertet und anschließend in der produktiven Umgebung technisch umgesetzt werden. Umso mehr solltet ihr es vorher druchgetestet haben. Da ich erst jetzt weiß von was du konkret sprichst... ja, wenn alle Stricke reißen könnte man das Benutzerobjekt z.B. löschen und durch eine autoritative Wiederherstellung das Benutzerobjekt vor der Änderung wiederherstellen. Natürlich muss vor der Änderung sichergestellt werden, dass eine funktionierende sowie aktuelle SYSTEM STATE Sicherung existiert. Abgesehen davon, bei einer Änderung am Benutzerobjekt ist die Gefahr sehr niedrig das Benutzerobjekt zu "zerschießen". Falls die Änderung nichts gebracht hat, löscht man i.d.R. den eingetragenen Wert einfach wieder raus. Hajo, wäre zwar machbar, aber wie gesagt, vorher in einer VM testen und du kannst dir die Mühe sparen. ;)

Aber selbstverständlich tut es das. Du sprichst von Verwaltbarkeit udn das mit 2 EDVlern... da ist schon ein Single-Domänen Forest schon fast Pflicht. Das musst du doch auch bei einer Umgebung mit nur einer Domäne nicht. Keep it simple lautet die Devise und das ist es eben bei nur einer Domäne. Und nur wenn du eine Domäne hast wird das System weder komplex, noch werden dadurch viele Objekte bzw. Subobjekte erstellt. Im Gegenteil, gerade wenn du mehrere Domänen erstellst, hat eben jede Domäne seine eigenen Objekte. Was die Berechtigungen anbetrifft, möchtest du also nichts im AD delegieren, dann brauchst du das auch garnicht. Alle Aufgaben in der Domäne werden dann von euch beiden ausgeführt. Somit sind die Aufgaben klar definiert und nichts großartiges zu Dokumentieren, was die Vergabe von Berechtigungen in der Domäen betrifft. Das Thema Virtualisierung ist ein ganz anderes, was dir aber im übrigen ebenfalls Vorteile verschafft. In vielen Unternehmen sind die EDV-Leute "Generalisten, adss ist ganz normal. Keineswegs. Ihr seit nicht die einzigsten auf dieser Welt mit den vielen Aufgaben. Und die Aussage "nur um die Pflege des AD kümmern" ist doch total verkehrt. Das AD ist ein Mittel zur Netzwerkverwaltung, nicht mehr und nicht weniger. Es hilft einem Unternehmen dabei, sich die Arbeit zu organisieren. Du kannst eine AD-Domäne wie eine NT-Domäne administrieren. Aber wie in jeder Umgebung, sollte man die Besonderheiten kennen. Ich persönlich halte das für genial. ;) Virtualisierung ist ein interessantes, aber kein leicht zu nehmendes Thema. Denn zusätzlich gilt es dann noch eine virtuelle Schicht zu administratieren. Und gerade bei dem Thema Virtualisierung gehört ein Konzept dazu. Du springst hier aber von einem Thema zum anderen. Na klar ist es das. Ich denke wenn du dir die Grundlagen angeeignet hast, wird einiges von ganz alleine klar. Auch dabei hilft dir der Artikel, denn es wird auf das ADMT verwiesen mit dem du die Benutzer- sowie Computerkonten in eine neue Domäne migrieren kannst. Denn somit bleiben die Profile erhalten und der Benutezr bekommt von der ganzen Aktion nichts mit. Das ADMT für Windows 2008 wird bald erscheinen.

Das ist aber in vielen Unternehmen so, denn schließlich hat jedes Unternehmen seine eigenen Anforderungen. Falls kein anderer DC (ab Windows 2000) mehr ereichbar wäre, ja. Wenn aber ein anderer DC in der Domäne noch verfügbar ist, egal an welchem Standort dieser steht, dann können sich die Benutzer an diesem DC authentifizieren. Das Imagen eines DCs halte ich für keine gute Idee. Yusuf`s Directory - Blog - Images als Sicherung ? Zum Thema Images bitte o.g. samt weiterführenden Artikeln lesen. Ich kann es bei 5 Benutzern zwar nachvollziehen, trotzdem könnte man sich die "Mehrarbeit" (Benutzer einrichten, Profile herrichten etc.) sparen und somit könnten die Benutezr schneller für die Firma Geld verdienen. Nein, oder sprichst du evtl. von DFS? Wozu gibt es denn Login-Scripts mit dem die Benutzer ihre Laufwerke auf ihrem Server vor Ort die Verbindung zu den Dateien herstellen? Doch, wäre es sehr wohl. Gerade da ihr nur zwei Mann in der IT seit, könntet ihr gewieften Angestellten die sich für die EDV interessieren, Aufgaben wie z.B. das erstellen der Benutzer delegieren (das ist nur ein sehr einfaches Beispiel). Denn schließlich habt ihr wichtigeres zu tun.

Moin, es kommt darauf an wieviele Werte in welchen Attributen ihr die Werte auf einmal ändern wollt. Tragt ihr z.B. Werte in den Attributen die zur Klasse USER gehören ein, könnt ihr die eingetragenen Werte auch leicht wieder ändern. Aber testet es doch vorher in einer Testumgebung aus. Ich würde mir dazu mit dem VMWare-Converter vorher einen DC virtuallisieren und die Änderung dann in einer Testumgebung, die natürlich keine Verbindung zur produktiven Umgebung hat, austesten. Dann seht ihr ja was passiert. Eine Autoritative Wiederherstellung wäre zwar eine Möglichkeit, aber bei 25 DCs (sind die wirklich notwendig?) eine Riesenakt. Eine System State Sicherung muss ohnehin existieren, mindestens vom FSMO-Rollen Träger oder besser von jedem DC. Das wäre eine Möglichkeit, das ihr auf dem DC wo ihr die Änderung durchführt die ausgehende (Outbound) Replikation und auf 23 DCs die eingehende Replikation deaktiviert. Somit erhält nur ein anderer DC die Änderung. Da ihr ja noch unsicher seit und die Auswirkungen noch nicht kennt, gehört das selbstverständlich vorher in einer Testumgebung getestet. Das Testen in der produktiven Umgebung wäre mehr als grob fahrlässig.