Daim

Servus dann füge einen zusätzlichen Windows Server 2008 DC zur bestehenden Domäne hinzu. Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen Doch, dass funktioniert. Du musst lediglich das ADPREP von einem 32Bit Medium ausführen und kannst anschließend, den 64Bit Windows Server 2008 zum DC stufen. Du könntest auch die 32it Trialversion vom Windows Server 2008 herunterladen und von dort das ADPREP ausführen. Nein, keineswegs. Bei einer Migration mit ADMT werden die Benutzer- (samt Profile) sowie Computerkonten in die neue Domäne migriert. Du musst die Clients weitestgehend nicht anfassen. Yusufs Directory Blog - Benutzermigration mit ADMT v3: How-To

Servus, kann es sein, dass du da etwas verwechselst. ;) Denn mit dem Erstellen der ersten Domäne einer neuen Gesamtstruktur, hast du bereits einen Forest. Würde gehen, aber nicht so wie du es dir vorstellst. Verständlich das es nicht geht. Du musst den DC zuerst mit DCPROMO Herunterstufen. Dann kannst du auf diesem DC mit DCPROMO eine neue Domänenstruktur (Tree) erstellen. Denn eine Domänenstruktur erstellt man i.d.R. nur, wenn die Einheit ihren eigenen Domänennamen bekommen soll. Es gibt aber nur einen einzigen globalen Katalog, über alle Domänenstrukturen hinweg.

Na das geht doch mit links. ;) DCs in VMs kann man machen, wobei ich ein Freund davon bin, die Infrastrukturdienste direkt auf physikalischen Maschinen laufen zu lassen. Aber das ist eher eine Glaubensfrage. Achte aber dabei für die Zukunft auf das Handling mit VM-DCs. Lies dir dazu die folgenden Artikel/Whitepaper durch: Considerations when hosting Active Directory domain controller in virtual hosting environments Download details: Using Domain Controller Virtual Machines Du könntest auch auf allen DCs den globalen Katalog aktivieren. Schaden tut es nicht und die Leitung gibt es ohnehin her. Du solltest das zwar ohnehin vorher testen, aber bzgl. der Profile kann ich dich beruhigen. Das ist doch gerade das schöne an ADMT. Die Profile bleiben alle samt erhalten. Der Benutzer merkt quasi nichts davon. Siehe: Yusufs Directory Blog - Benutzermigration mit ADMT v3: How-To Yusufs Directory Blog - ADMT Version 3.1 Wie gesagt, in den Aussenstandorten würde ich je einen RODCs platzieren. Nur in der Zentrale sollten zwei beschreibbare 2008er DC vorhanden sein. Den globalen Katalog kannst du ruhig auf allen DCs aktivieren. Ich würde eher Auswandern. :D

Ich würde ganz klar bei ca. 640 Clients auf das Ein-Domänen Modell migrieren. Dann bräuchtest du in den Standorten nicht zwei, sondern je einen DC aufstellen. Das spart Hardware- sowie Lizenzkosten. Die DCs können dann natürlich noch weitere Aufgaben wahrnehmen. Das Problem bei diesem Vorhaben ist dabei eben der Faktor "Mensch". Denn es müssen nicht alle IT-Mitarbeiter Domänen-Admins sein. Du kannst Berechtigungen im AD exakt delegieren. Somit beschneidet man die ITler von Ihren gewohnten Rechten. Aber SIE wurden schließlich von euch übernommen. ;) In den Aussenstandorten würde ich jeweils einen RODC aufstellen, der zusätzlich noch weitere Aufgaben übernehmen kann. In der Zentrale würde ich dann zwei beschreibbare Windows Server 2008 DCs aufstellen. Yusufs Directory Blog - Read-Only Domain Controller (RODC) http://blog.dikmenoglu.de/PermaLink,guid,9ccc45e9-65f7-4ad5-977c-b8003248679a.aspx Siehe auch: Yusufs Directory Blog - Objektdelegierungen einrichten Das ist eine tolle, aber auch anspruchsvolle Herausforderung. Du solltest dir dabei über externe Hilfe Gedanken machen.

Salut, der Domänenname ist aber nicht verkehrt. Er stellt zumindest genau meine favorisierte Variante, nämlich eine Subdomäne zum externen Internet-Auftritt dar. Rechtfertigt denn die Größe der aufgekauften Unternehmen, dass diese in eine Sub-Domäne migrieert werden sollen? Denn für die leichtere Administration wäre ein Single-Domänen Forest zu bevorzugen. Falls ihr Berechtigungen delegieren wollt, könntet ihr das wesentlich besser über OUs regeln. Das ist leichter, flexibler und spart Lizenzen sowie Hardware für Server. Der Nachteil bei mehreren Domänen wären: - Bei mehreren Domänen ist der adminstrative Aufwand (Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte. - Dadurch entstehen hohe Hardware- sowie Lizenzkosten. - Jeder DC sollte/muss vor Ort physikalisch geschützt sein. - Jede Domäne muss gesichert werden (Backup). Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden. Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Ich würde auch gleich Windows Server 2008 empfehlen. Genau. Aber denke daran, DCs können mit keinem Tool migriert werden. Diese müssen aus der alten Domäne zuerst herunter- und in der neuen Domäne erneut Heraufgestuft werden. Ich weiß, es ist oftmals ein politisches Problem. Aber was die Administration betrifft, könntest du das gezielter durch die Objektdelegierung erreichen, bei einem Einzeldomänen-Modell. Daher würde ich, wenn es sich nicht um allzu große Umgebungen handelt, auf das Ein-Domänen Modell plädieren. Als Tipp: Wenn in den Aussenstandorten der DC physikalisch nicht sicher steht, solltest du vor Ort RODCs einsetzen.

Off-Topic: Wow... drei Antworten in derselben Minute... wann hat es denn das schon einmal gegeben. ;)

Servus, nein, dass geht nicht. Du kannst nicht XP - ein Client-Betriebssystem - auf Windows Server 2003 - einem Server-Betriebssystem - aktualisieren.

Salut, nein, dass Verhalten unter Windows Server 2008 ist das gleiche wie unter Windows Server 2003. Du musst im LDP als BASE DN den unsichtbaren Conainer "Deleted Objects" in der Domänenpartition angeben. Dies sieht wie folgt aus: "CN=Deleted Objects,DC=Domäne,DC=TLD". Als Filter könntest du dann (objectclass=user) verwenden. Siehe auch: Windows Server: Tombstone-Wiederbelebung in Active*Directory http://blog.dikmenoglu.de/PermaLink,guid,832d2e97-71fb-4fc6-83eb-63f4f849fc44.aspx Du müsstest ein Forest Recovery durchführen, denn die Schemapartition kann nicht autoritativ wiederhergestellt werden. http://support.microsoft.com/kb/241594/en-us Download details: Forest Recovery Es sei denn, die Schemaerweiterung wurde clever durchgeführt in dem z.B. der Schemamaster in ein isoliertes Netz gesteckt und dort die Aktualisierung vorgenommen wurde. Dann könntest du lediglich den DC herunter- und anschließend wieder Heraufstufen wenn etwas schief gehen würde. Aber es kommt immer darauf an, welches Tool die Erweiterung durchführt und mit welcher Intelligenz. Bei einer Schemaerweiterung mit den Microsoft-Tools hatte ich noch nie Probleme. Zum Überprüfen des DCs reichen z.B. die Tools DCDIAG sowie NETDIAG völlig aus. Natürlich stecken noch weitere nützliche Tools in den Windows Support Tools, die bei der täglichen Administration nicht fehlen sollten. Als Dritt-Anbieter Tools sind die Tools von Quest zu empfehlen. Es gibt aber auch ettliche weitere die genauso gut sind.

Servus, pauschal: Ein zweiter DC macht immer Sinn. Dabei kommt es natürlich auf den Workflow der Firma an. In einer kleinen Firma mit vielleicht 5 Benutzern könnte man schon denken, dass ein zweiter DC zu oversized ist. Aber dieser zweite DC muss natürlich nicht nur ein reiner DC sein. Dieser kann natürlich weitere Aufgaben wahrnehmen. Die Hardware des zweiten DCs könnte dabei eine Client-Hardware sein und auch dann, kann die Maschine weitere Aufgaben wahrnehmen. Welche das sind, muss natürlich vor Ort entschieden werden. Auch wenn es nur das drucken wäre... Aber wenn z.B. die Clients viele Arbeiten lokal ausführen, also z.B. viele Briefe geschrieben und gedruckt werden, wobei evtl. an jedem Client LOKAL auch noch ein Drucker hängt, macht ein DC vielleicht weniger Sinn. Es kommt eben auf den Arbeitsprozess vor Ort an. Wie arbeiten die Mitarbeiter mit welchen Applikationen. Existieren mehrere Netzwerkapplikationen, könnte man diese eben auf zwei DCs verteilen. So könnte bei einem Crash des einen DCs, die Authentifizierung und die Hälfte der Netzwerkapplikationen noch weiter auf dem anderen DC genutzt werden. Der kluge Aufbau der vor Ort existierenden Situation, ist das A und O. Zusammen mit dem Kunden kann man diese klären. Was ist ihm wichtig, worauf kommt es ihm an, was sollte bei einem Crash trotzdem weiterhin funktionieren usw. usf.

Kann er nicht. Ist zumindest nicht verkehrt. Mit der Delegierung kannst du eben gezielt auf eine OU die Berechtigungen vergeben. Die Mitglieder der Gruppe Konten-Operatoren können Domänen-Benutzer, Gruppen- und Computerkonten in der Domäne verwalten über alle Container hinweg. Den Mitgliedern ist jedoch nicht möglich, die Gruppen Administratoren oder Domänen-Admins, das Adminkonto oder die Computerkonten der DCs in der OU Domain Controllers zu bearbeiten.

Servus, warum? Wenn du ein entsperchendes Rollenkonzept ausarbeitest, muss der Mitarbeiter kein Domänen-Admin sein. Was z.B. die AD-Aufgaben betrifft, kannst du die Objektdelegierung nutzen. Du musst eben erstmal klarstellen, was soll der Kollege alles ausführen können. Yusufs Directory Blog - Objektdelegierungen einrichten Yusufs Directory Blog - Der Objektdelegierungsassistent Er darf kein Domänen-Admin sein, denn ansonsten kann er jederzeit in den Ordner schauen. Oder du nutzt Dritt-Anbiter um diese Verzeichnisse gesondert zu sichern.

Servus, siehe: How to completely remove Exchange 2000 or Exchange 2003 from Active Directory How to remove Exchange Server 2003 from your computer How to manually remove an Exchange 2000 installation

Servus, naja, wenn du an alles weitere denkst, hat das keine sonderlichen Auswirkungen. Änderst du die IP-Adrese eines DCs, müssen alle Dienste sowie evtl. bestehende Netzwerkapplikationen angepasst werden, die von der IP-Adresse des DCs abhängig sind. Dienste wie DHCP, DNS, WINS etc. gilt es dann ebenfalls anzupassen. Yusufs Directory Blog - Die IP - Adresse eines Domänencontrollers ändern

Yepp... die Einstellung "Persönliche Informationen schreiben" dürfte schon in die richtige Richtung gehen.

Servus yepp, da gibt es genügend Parkmöglichkeiten vor den Toren von Rom... ähhmm... ich meine vor den Hallen in Lingen. ;)

Servus, erstelle im Snap-In "Active Directory-Standorte und -Dienste" einen AD-Standort samt Subnetz für die Zweigstelle. Dort sollte sich dann der Zweigstellen-DC befinden. Steht denn der Server in der Zweigstelle auch physikalisch sicher? Denn wenn dies nicht so wäre, solltest du davon absehen vor Ort einen DC aufzustellen. Es sei denn wir reden hier von Windows Server 2008 Systemen, denn dann könntest du vor Ort einen RODC aufstellen. Somit würde sich das Thema Sicherheit wiederum entschärfen. Ansonsten siehe: Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen Wenn du AD-Standorte erstellst, könntest du mit standortbezogenen GPOs arbeiten.

Servus, warum möchtet ihre für die neuen Standorte Sub-Domänen erstellen und integriert die Standorte nicht einfach zur bestehenden Domäne? Handelt es sich um eine große Umgebung? Was das Domänenmodell anbetrifft, bin ich ein Freund vom Single-Domänen Forest. Der Nachteil bei mehreren Domänen wären: - Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte. - Dadurch entstehen hohe Hardware- sowie Lizenzkosten. - Jeder DC sollte/muss vor Ort physikalisch geschützt sein. - Jede Domäne muss gesichert werden (Backup). Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden. Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Ich persönlich tendiere gerne zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten darauf an. Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen. Möchtest du weiterhin die neuen Standorte in Sub-Domänen migrieren, sollten idealerweise die neuen Sub-Domänen bereits existieren. Denn wenn bereits die Sub-Domäne besteht, kann man recht einfach mit ADMT die Benutzer- sowie Computerkonten von einer Domäne in die andere migrieren. Yusufs Directory Blog - Benutzermigration mit ADMT v3: How-To Dann solltest du dir in der Tat Hilfe von einem Dienstleister holen. Das ist keine triviale Angelegenheit.

Off-Topic:Fehlanzeige. Die näheren Bekannten glauben auch das mein Nickname von dem Schokoriegel stammt. Das hätte auch gut sein können, da meine Zigarette und mein Bier (was ich beides nicht nutze) --> Schokolade ist. Ich bin sozusagen ein Süßmaul :). Da ich von der Old School Zeit stamme und in der Hip-Hop/Breakdance/Graffiti Szene aktiv war, war ich ein bewunderer eines Graffiti-Künstlers namens Daim. Weißt du! ;)

Servus, siehe: Yusufs Directory Blog - LDIFDE - LDAP Data Interchange Format Data Exchange

Off-Topic:Ohh... Herr Röder... welch eine Ehre Sie hier ebenfalls begrüßen zu dürfen. Ein coolerer Nickname ist dir aber nicht eingefallen oder wie? ;)

Salut, Best Practice ist es in jedemfall die Forward Lookup Zone (FLZ) AD-integriert zu speichern. Denn dadurch werden die DNS-Informationen durch die AD-Replikation automatisch auf die DCs repliziert. Leider verschweigst du die eingesetzten Serverversionen. Wenn du ausschließlich Windows Server 2003 DCs (oder höher) im Einsatz haben solltest, würde sich bei der DNS-Konfiguration, beim Erstellen der FLZ die Einstellung "Auf allen DNS-Server in der Domäne (unten die Option 2)" anbieten. In Windows 2000 befinden sich die Active Directory-integrierten DNS-Informationen in der Domänenpartiton (wo sich z.B. auch die Benutzer und Gruppen etc. befinden) und können daher nur innerhalb der Domäne repliziert werden. In Windows Server 2003 hat man nun die Möglichkeit selbst zu bestimmen, wo bzw. in welchen Verzeichnispartitionen die DNS-Informationen gespeichert werden sollen. Dort sind die folgenden Optionen möglich: 1. Auf alle DNS-Server in der AD-Gesamtstruktur. Somit werden die DNS-Informationen in einer neuen Anwendungsverzeichnispartition "ForestDNSZones" gespeichert. Die DCs müssen Windows Server 2003 sein. 2. Auf alle DNS-Server in der Domäne. Somit werden die DNS-Informationen in einer neuen Anwendungsverzeichnispartition "DomainDNSZones" gespeichert. Die DCs müssen Windows Server 2003 sein. 3. So wie bei Windows 2000 in der Domänenpartition. Hierzu findet man im ersten Reiter der Zoneneigenschaften oben die Konfigurationsmöglichkeit.

Na, genau so wie ich es geschrieben habe. Wenn du einen DC herunterstufen möchtest, fragt dich der Assistent ob dies der letzte DC einer Domäne ist. Dabei spielt es keine Rolle ob es sich tatsächlich um den letzten DC einer Domäne handelt. Du musst dann durch aktivieren des Kontrollkästchen dem Assistenten mitteilen, dass es sich um den letzten DC einer Domäne handelt. Ist es nicht der letzte DC einer Domäne, setzt du einfach den Haken nicht. Wenn der Haken gesetzt ist, wird die Domänenpartition aus der Gesamtstruktur entfernt. Nicht zu vergessen die Clients.

In welchen Städten wärst du denn dabei? Mainz - Frankfurt - Darmstadt - Wiesbaden - ...

Servus, ja, du kannst mit ADMT [1] die Benutzer- sowie Computerkonten von einer Domäne in die andere migrieren, aber keine DCs. Diese müssen aus der alten Domäne zuerst herunter- und in der neuen Domäne erneut heraufgestuft werden. [1] Yusufs Directory Blog - ADMT Version 3.1 Natürlich. Wenn du den letzten DC einer Domäne herunterstufst, fragt dich der DCPROMO-Assistent gleich zu Beginn, ob dies der allerletzte DC der Domäne ist. Erst wenn du den Haken gesetzt hast, wird neben dem Herunterstufen des DCs, auch die Domäne von der Gesamtstruktur entfernt. Hast du schon einmal den Trust im Snap-In Active Directory-Domänen und Vertrauensstellungen geprüft? Oder mit NETDOM aus den Windows Support Tools. Dann kannst du doch als nächstes den Trust erneut, diesmal mit NETDOM einrichten. Aber trotzalledem ist die Administration einer Domäne bei dieser Größe des Netzes, das einfachere Domänenmodell.

Huhuu, yepp, ich wäre mit von der Partie und danke Gulp für die Umfrage. :)