Daim

Das mit den Anführungszeichen solltest du dir in der Praxis angewöhnen. Diese benötigst du, wenn im Distinguished Name (DN) ein Leerzeichen auftaucht. Also wenn der Pfad z.B. so lauten würde: OU=IT Abteilung,DC=Domäne,DC=TLD dann musst du den DN in Anführungszeichen setzen (Leerzeichen zwischen "IT" und "Abteilung"), ansonsten nicht. Aber wie gesagt, gewöhne dir das für den Tag täglichen Job an, dann stolperst du zumindest nicht über diesen Stein. ;)

Servus, es deutet darauf hin, dass es am Computerkontokennwort liegt. Führe NETDOM RESETPWD durch. Netdom findest du in den Windows Support Tools.

Moin, also ich habe es soeben in einer Windows Server 2003 Umgebung mit dem Standard-Container Users sowie der OU Domain Controllers getestet, funktionierte tadellos. Dabei habe ich diese Befehle verwendet: Csvde -f Export.csv -d "cn=users,dc=intra,dc=contoso,dc=com" oder Csvde -f Export.csv -d "ou=domain controllers,dc=intra,dc=contoso,dc=com"

Moin, genau so. Ein Umzug erfolgt manuell, in dem Du beim Clearing-House anrufst und die Lizenznummern erneut für den neuen Server freischalten lässt. Also musst du bei der Aktivierungsmethode "Telefon" wählen. Siehe dazu: Terminal Services - Frequently Asked Questions - Licensing Aber ein TS sollte niemals auf einem DC installiert werden...

Salut, ja, das ist auch so. Aber der OP schrub in seinem OP: Zitat: Demzufolge kann sich der Domänenfunktionsmodus nur im Modus "Windows 2000 gemischt" oder "Windows 2000 pur" befinden.

Du hast es aber immer noch nicht verstanden. Das ist genau das Problem. Wenn mit einem bestehenden DC ein Domänen-Splitt durchgeführt wird, hat die ANDERE Seite, die Domäne, die einen bestehenden DC übernimmt, alle Kennwörter eurer Domäne. Somit ist eure Umgebung nicht mehr sicher. Vorher wußtest du noch nicht bescheid, ich hoffe das du nun mit dieser Antwort bescheid weißt. Das ist der einzig durchführbare Weg!

Genau, die Profile, sei es lokale- oder servergespeicherte Profile bleiben alle samt erhalten. Korrekt. 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 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. Es ist Freitag kurz vor Feierabend, du willst nicht das ich mich aufrege (nein, das willst du nicht wirklich). Wer so einen Domänen splitt durchführt, gehört geteert+gefedert+vor das Kriegstribunal+und was weiss ich noch alles. Im Ernst, vergiss diese Variante, denn somit werden auch die ganzen Kennwörter mitgenommen. Daher schrub ich bereits zu Beginn das die einzige Möglichkeit die Migration mit ADMT ist. Höre auf an dieser Stelle WEITER ZU DENKEN!

Servus, ja, kannst du. In dem du mit ADMT in eine neue Domäne migrierst. Doch, dass musst du aber und es führt kein Weg daran vorbei. Das Tool das dir dabei behilflich ist, nennt sich ADMT. Damit kannst du die Benutzer- sowie Computerkonten in die neue Domäne migrieren, ohne das der Benutzer davon etwas mitbekommt. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Na na... ADMT 3.1 ist noch nicht offiziell verfügbar. Das Tool ist noch in der Beta.

Moin, falls der Bewerber ein MCSE ist, dann würde ich zwei Fragen aus dem DNS-Bereich stellen (Stubzone, Weiterleitung). Aus dem AD-Bereich würde ich gezielt auch eins-zwei Fragen nach den FSMO-Rollen stellen (wieviele RIDs bekommt jeder DC, für was ist der PDC-Emu. zuständig). Und vielleicht noch eins-zwei allgemeine Netzwerkfragen.

Off-Topic: Booaahh Sven, also so tief hatte Güntha bisher noch nicht geschlagen. ;)

Warum denn, dass ist halb so schlimm und tut auch nicht weh. ;) Du kannst alle Rollen über die GUI übertragen, bis auf den RID-Master. Diesen (oder eben alle Rollen) musst du zwingend mit NTDSUTIL seizen.

Off-Topic:Güntha, du schlawiner. Wie sehr wünsche ich mir, dass in der EM die Türken gegen die Österreicher spielen. ;)

Salut, das halte ich für keine gute Idee. Genau so solltest du Vorgehen. Übertrage zuerst die FSMO-Rollen "mit Gewalt" (seize) auf den anderen DC. Zusätzlich solltest du auf allen DCs den globalen Katalog aktivieren. Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Entferne danach den gecrashten DC aus dem AD mit NTDSUTIL oder ADSIEdit. Du könntest auch den gecrashten DC händisch aus allen DCs entfernen, besser ist aber die Vorgehensweise mit NTDSUTIL/ADSIEdit. How to remove data in Active Directory after an unsuccessful domain controller demotion Nach diesen Aktionen, repariere den gecrashten Server, installiere ihn neu und füge ihn mit DCPROMO als zusätzlichen DC zur bestehenden Domäne hinzu. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Dem Server kannst du die gleiche IP-Adresse sowie den gleichen Computernamen wie er ihn vor dem Crash hatte geben. Wichtig ist eben, dass du vorher das AD bereinigst damit der Server den gleichen Namen bekommen kann. Ich hoffe das du nun weißt was zu tun ist. ;)

Servus, wie wäre es denn, wenn du uns noch mitteilen würdest welche Bandbreite zwischen den Standorten zur Verfügung steht. Dann kannst du dir auch schon einiges selbst beantworten, nämlich, was soll vor Ort verfügbar sein, wenn die VPN-Leitung down ist? Also was soll dann das Aussenbüro noch können? Wenn du dir darüber im klaren bist, hast du schon diverse Antworten auf deine Fragen. ;)

Servus, nein - no - nada - hayir - niet. Es macht nie Sinn einen TS auf enem DC zu installieren und zwar aus genau dem Grund, den IThome genannt hat.

Servus, korrekt. So wie die Schemapartition existiert gesamtstrukturweit auch eine gemeinsame Konfigurationspartition die auf allen DCs egal in welcher Domäne der GLEICHEN Gesamtstruktur sie stehen, repliziert. Ist die Replikation bereits erfolgt?

Es führen bekanntlich viele Wege ans Ziel. Man muss ja nicht zwingend einen anderen als DNS-Server eintragen, man kann und sollte es aber. Funktionieren tut es im Betrieb so oder so. Nur kann es dann eben bei einem Neustart des DCs zu Fehlermeldungen oder Verzögerungen kommen. Das ist aber auch nicht sooo dramatisch, da der DC nicht permanent neu gestartet wird (hoffe ich doch). @dankon7goo Er heißt "Yusuf". ;)

Aloha, nein, stimmt nicht. Genau, man kann sie definieren und diese ist dann nicht 50 MB sondern max. 30 MB. Aber auch diese Grenze lässt sich ändern. Siehe: Yusuf`s Directory - Blog - Profile (lokal/servergespeichert) Völliger Unfug. @Sven: Mach mal halblang. Bist ja schon wieder schneller heute. ;)

Wenn die Firma Kompetent war... ist das natürlich doof. Das ist garnicht schwer. Wichtig ist das sich die Domänen IP-technisch erreichen können. Das Routing muss also stehen. Dann richtest du eine Vertrauensstellung in der MMC "Active Directory-Domänen und -Vertrauensstellungen" ein. Die Suchmaschine deines Vertrauen hilft dir dabei. ;) Technisch eben nicht möglich. Tue das. ;)

Salut, wenn der Windows 2000 Server ein Mitgliedsserver in der Windows Server 2003 Domäne werden soll, dann fügst du diesen Server ganz normal wie einen Client zur Domäne hinzu. Dabei gibt es nichts zu beachten. Er wird wie ein Client zu der Domäne hinzugefügt und ist dann ein Memberserver. Soll aber der Windows 2000 Server ein Domänencontroller werden, hängt es davon ab, in welchem Domänenfunktionsmodus sich die Domäne befindet. Wenn sich der Modus im "Windows Server 2003 Interim" oder "Windows Server 2003" befindet, so kann der 2000er Server kein DC mehr werden. Bahnhof? Wie nicht weiter ausgeführt? Wenn der 2000er ein Memberserver werden soll, dann nicht. Dann trägst du in den TCP/IP-Einstellungen die entsprechenden IP-Informationen ein. Falls er ein DC werden soll, hängt es eben vom DFL ab.

Servus, was lässt dich diese Annahme vermuten? Du willst also in eine neue Domäne migrieren. Hast du schon versucht die Fehler zu beseitigen? Mit externer Hilfe? Yepp, dass Tool heißt ADMT. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauensstellung 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. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Klar, denn diese sind einmalig bzw. im Falle der SID, hängen diese von der Domäne ab.

Du meinst vermutlich, in die Eigenschaften des NTDS SETTINGS Objekts unterhalb des DCs und dort im Reiter Verbindungen. ;) Yes, Sir.

Richtig. Aber ChristianHemker hat schon einen berechtigten Einwand gebracht. Das trifft z.B. auf das Drucken zu. Also wenn an dem XP-Client ein Drucker freigegeben wäre und jemand würde durch die Druckerfreigabe darauf drucken, wird diese Verbindung nicht direkt nach dem drucken wieder freigegeben, sondern ca. 15-30 Minuten später. Je nach Drucker (Treiber).

Off-Topic:Du warst nicht zufällig der Verursacher, oder? :p