Daim

Warum eigentlich nicht. Evtl. könnte man daraus ein Rhein-Main Treffen organisieren. @Gulp Würdest du eine Umfrage starten damit wir sehen, wer alles dabei wäre?

Servus, schau auch mal hier: Yusufs Directory Blog - Die letzte Benutzeranmeldung herausfinden

OK. Nur hättest du CISCO gleich erwähnen können, denn dann hätte man die Situation gleich entwarnen können. Bzgl. des Callmanagers/Unity brauchst du dir keine Gedanken machen. Das läuft problemlos. Das Produkt stammt schließlich von einem namhaften Hersteller.

Servus, meinst du ein "Resourcen Forest Modell"? Forest Design Models: Domain and Forest Trusts; Domain Name System (DNS); Active Directory Grob gesagt, du erstellst einen neuen Forest und packst die Ressourcen in diesen Forest. Das könnten jegliche Art von Applikationsservern sein. In der Ressourcen Gesamtstruktur befinden sich dann aber nicht die Benutzerkonten. Die Ressourcen-Server werden somit gesondert in ihrer eigenen Gesamtstruktur gesichert. Zwischen beiden Gesamtstrukturen wird dann eine Vertrauensstellung (entweder eine externe- oder Gesamtstrukturvertrauensstellung ab Windows Server 2003) eingerichtet. Zwischen beiden Gesamtstrukturen könnte dann noch eine Firewall stehen, die den Zugriff regelt. "Verwurstelt" hört sich an dieser Stelle zwar etwas ulkig an, aber ja, genau so ist es. Such mal im Internet nach "Ressourcen Forest". Aber im Prinzip müsste dir es doch nun nach meinen Erläuterungen einleuchten, oder? Eine Awendung gehört natürlich in einer Testumgebung getestet. Aber warum sollte dann die Testumgebung eine Verbindung zur produktiven Umgebung haben? Um die Applikation zu testen? Diese sollte wenn möglich in der Testumgebung getestet werden.

Salut, dann kontrolliere das Eventlog und gehe den Fehlereinträgen auf der Seite EventID.Net - Troubleshooting information for Windows event logs nach. Mit welcher Fehlermeldung denn? Wenn bereits der Computername existiert hätte, wäre die Fehlermeldung eindeutig gewesen. Du kannst zusätzlich das DCPROMOUI.log kontrollieren, um weitere Details zu erfahren.

Buenos dias, ... und CSVDE (kann es zumindest auch). Was genau im Falle von ADPREP der Fall ist. Das ADPREP macht ja auch nichts anderes, als LDF-Dateien ins Schema zu importieren.

Bonjour, dieser wäre passender gewesen: ;) Yusufs Directory Blog - Einen Standort umbenennen

Wenn die Lösungen von renommierten Herstellern oder von Herstellern die wissen was sie tun stammen, wird es keine Probleme geben. Du kannst dir das auch von den Herstellern bestätigen lassen. Die Aktualisierungen die das ADPREP vornimmt, kannst du hier sehen: Microsoft Corporation

Servus, du kannst dir auch eine LDIF-Datei erstellen und dann mit LDIFDE in einer Kommandozeile den Standort erstellen. Neben der skriptbasierten Variante, kannst du auch noch ADMOD von welcome to joeware in der Kommandozeile nutzen.

Servus, dann solltest du zuerst ein /FORESTPREP mit einplanen. ;) http://blog.dikmenoglu.de/PermaLink,guid,58a3c79f-f34e-4635-bc5f-0bfc67045b91.aspx Ja, die Ausgangssituation sollte schon in Ordnung sein. Du rufst die Seelenfürsorge an. :D Nein, im Ernst. Wenn im Schema des AD alles Standard ist, brauchst du dir keine Gedanken zu machen. Es kommt ja auch auf das Tool an mit dem du die Schemaaktualisierung durchführst. Das ADPREP das ja von Microsoft stammt, ist so intelligent genug um bei einem Abbruch von dort weiter zu Verfahren, wo es stehen geblieben ist. Wenn du trotzdem das ganze noch sicherer handhaben möchtest, kannst du den Träger der FSMO-Rollen und einen weiteren DC in ein eigenes Subnetz stecken und die Schemaerweiterung dort ausführen. Wenn dann die Schemaaktualisierung auf den anderen DC repliziert wurde, hängst du beide DCs erneut ins Netzwerk zurück. Mit dem ADPREP musst du dir keine Gedanken machen, wenn im Schema nichts gepfuscht wurde. Heikel? Du musst wissen was du tust, mehr nicht. ;)

Servus, dann wurde wohl vorher gebastelt oder es liegt ein Irrtum vor. Denn standardmäßig existiert der Container CN=Users bereits. Wenn man nun eine OU mit dem Namen Users einrichten wollte, sagt einem das System das bereits dieser Name in Verwendung ist. Die OU lässt sich nicht mit diesem Namen einrichten.

Servus, auf welchen DCs der globale Katalog aktiviert ist, erfährst du bei einer Abfrage mit NSLOOKUP oder DSQUERY. Siehe: Yusufs Directory Blog - Globaler Katalog (Global Catalog - GC)

Nein.

Dann repariere den DC (ohne Neuinstallation) und du brauchst garnichts rückzusichern. :D

Nicht so ohne weiteres, ist aber auch in deinem Fall keineswegs notwendig. Beachte in dem folgenden Artikel den Bereich "Moving a Windows domain controller installation". How to move a Windows installation to different hardware Musst du doch nicht. Du reparierst den DC, installierst von mir aus das OS neu und stufst ihn ganz normal als zusätzlichen DC zur Domäne hinzu. Vorher musst du den DC eben aus dem AD entfernen. Dazu beachte den Artikel in meiner vorherigen Antwort.

Servus, bei einem zusätzlichen DC, kannst du zuerst den Server aus dem AD entfernen [1] und stufst ihn anschließend nach der Reparatur des Servers, erneut zum DC. Das rücksichern im Fall eines zusätzlichen DCs ist nicht zwingend notwendig. [1] Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Salut, ja, dass würde funktionieren. Entscheidend ob ältere DCs installiert werden können ist hier der Domänenfunktionsmodus. Allerdings würde ich das Schema lediglich auf die Version aktualisieren, auf die ich die DCs aktualisieren möchte. Wenn die Windows 2000 DCs durch Windows Server 2003 DCs ersetzt werden sollen, würde ich das Schema auf die Version 30/31 aktualisieren. Denn das Schema kannst du jederzeit wenn du auf Windows Server 2008 aktualisieren möchtest, noch aktualisieren. Warum also vorher aktualisieren? Deine Frage wird aber auch nicht jeden Tag gestellt und ist für viele sicher nicht relevant. Daher wird in dem Artikel diesbezüglich nichts erwähnt.

Dieser Test wird gerade in KMU-Umgebungen erst im Ernstfall durchgeführt. Dann also, wenn bereits das Kind in den Brunnen gefallen ist... leider.

Servus, natürlich kannst du dich in dem Modus "Verzeichnisdienste wiederherstellen" nicht mit einem Domänen-Account anmelden, da ja das AD offline ist. Du musst dich mit dem Konto für den Wiederherstellungsmodus anmelden. Das Kennwort wird bei dem Heraufstufen zum DC vergeben. Falls dir das Kennwort nicht mehr bekannt sein sollte, kannst du das Kennwort für den DSRM zurücksetzen. Siehe: How to Change the Recovery Console Administrator Password on a Domain Controller How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003 Gerade das rücksichern von Benutzern oder Gruppen und deren Mitgliedschaften ist etwas besonderes. Dazu beachte diesen Artikel: How to restore deleted user accounts and their group memberships in Active Directory Denn wie die anderen hier geschrieben haben, bringt dir das wiederherstellen des Tombstones herzlich wenig in Bezug auf die Gruppenmitgliedschaften. Denn das member Attribut im Gruppenobjekt wird eben nicht im Tombstone gespeichert. Daher solltest du für die Zukunft gerade für das wiederbeleben des Tombstones gesondert Vorgehen. Beachte dazu den o.g. sowie den folgenden, samt weiterführenden Artikeln: Yusufs Directory Blog - Active Directory Wiederherstellung

Völliger Unsinn. Das ist ja gerade der große Vorteil von dem ADMT. Du musst lediglich das Tool ausführen. Es kann allerdings vorkommen, dass vereinzelte Clients Probleme machen und diese zwei-drei mal neugestartet werden müssen, ehe diese migriert werden können. Ganz hartnäckige Clients lassen sich auch garnicht migrieren, so das du diese händisch zur neuen Domäne hinzufügen musst. Dies tritt aber eher selten auf. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauenesstellung benötigt. Das ADMT richtet ein neues Benutzerkonto in der neuen Domäne ein und fügt die SID des alten Benutzerkontos, aus der alten Domäne an das neue Benutzerkonto der neuen Domäne als SID-History hinzu. 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 Benutzername gleich lautet. Denn bekanntlich sind /Namen/ "Schall und Rauch" in der IT. Im ersten Schritt werden mit ADMT die Benutzer- und im zweiten die Computerkonten migriert.

Servus, natürlich kennen wir das Programm. Es lautet ADMT. Yusufs Directory Blog - Benutzermigration mit ADMT v3: How-To

Das bringt ihm nicht viel, wenn er unter Windows 2000 nicht die Windows Support Tools, entweder von der Windows 2000 Server CD aus dem Verzeichnis Support/Tools oder aus dem Internet [1] heruntergeladen und installiert hat. ;) [1] Download details: Windows 2000 Service Pack 4 Support Tools

Also dieses Thema hatten wir in der Vergangenheit wirklich schon etliche Male besprochen... Lies in dem folgenden Artikel, den Bereich "General recommendations for FSMO placement". FSMO placement and optimization on Active Directory domain controllers

Wenn die Gesamtstruktur lediglich aus nur einer Domäne besteht, quasi ein Single-Domänen Forest existiert, dann gibt es für den Infrastrukturmaster keine Arbeit und es spielt keine Rolle, ob der DC auch GC ist oder nicht. Denn es existieren ja keine weiteren Domänen von denen Objekte repliziert werden, die der Infrastrukturmaster vergleichen müsste. Existieren in einer Gesamtstruktur mehrere Domänen (Multi-Domänen-Forest), darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC.

Servus, ich führe mal die einzelnen Schritte auf: Zuerst sollte natürlich ein Backup existieren. Falls der neue Server der erste Windows Server 2003 --> R2 <-- sein sollte, musst du vorher das Schema mit ADPREP /FORESTPREP von der zweiten R2-CD aktualisieren. Du fügst dann die neuen Server als zusätzliche DCs der bereits bestehenden Domäne hinzu und installierst idealerweise auf jedem DC auch das DNS. Dabei sollte die Forward Lookup Zone idealerweise AD-integriert gespeichert sein, denn dann erledigt die AD-Replikation für dich den Rest. Auf dem ersten DC sollte das DNS schon AD-integriert gespeichert sein. In den TCP/IP-Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS-Server den bestehenden DC als primären DNS-Server ein und änderst erst die IP-Adresse, wenn die Replikation stattgefunden hat. Somit hast Du das AD und DNS auf Deinen neuen DC "übertragen". Danach musst Du die 5 FSMO Rollen auf den neuen DC verschieben. Genau genommen musst du zwar die Rollen nicht manuell verschieben, denn bem herunterstufen werden diese bei bestehen weiterer DCs automatisch verschoben, doch diese solltest du trotzdem händisch verschieben um dir über diesen Schritt bewußt zu sein. How to view and transfer FSMO roles in the graphical user interface Zusätzlich solltest Du die neuen DCs zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Bevor Du den alten DC mit DCPROMO aus der Domäne nimmst, sichere noch das EFS-Zertifikat. Den Artikel hat dir bereits Norbert gepostet. Die DHCP Datenbank kannst Du exportieren: How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003 WINS solltest Du ebenfalls installieren, denn der WINS erleichtert Dir das tägliche Leben. Freigaben könntest Du ebenfalls exportieren und auf dem neuen Server importieren: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares Drucker kannst Du mit dem Print Migrator kopieren/verschieben: Download details: Windows Print Migrator 3.1 Dann musst du ggf. noch das Anmeldeskript anpassen. Die Daten kannst Du mit NTBACKUP Sichern und auf dem neuen wiederherstellen oder mit ROBOCOPY verschieben. Zum Schluss wenn dann alle Daten sowie Dienste vom DC übernommen wurden, nimmst du diesen ordnungsgemäß mit DCPROMO aus der Domäne. Nein. Naja, worauf zu achten ist habe ich dir bereits geschrieben. Probleme können immer und jederzeit auftauchen, aber das muss man dann von Fall zu Fall bewerten und schauen, wie man den Fehler behebt. Fallstricke in dem Sinne gibt es nicht. "Deaktivieren" ist hier unglücklich ausgedrückt. Der DC gehört mit DCPROMO ordnungsgemäß aus der Domäne entfernt, andernfalls bleibt noch eine Leiche im AD. Ich habe dir einen Weg aufgezeigt.