Daim

Es spricht nichts gegen den Windows Server 2008, du musst dich lediglich entscheiden welchen Weg du gehen möchtest. Du kannst auf der neuen Maschine einen Windows Server 2008 installieren und auf diesem eine neue Domäne einrichten. Das bedeutet dann wiederum, du müsstest alle Benutzer neu einrichten und müsstest somit die Profile anpassen sowie die Clients dann zur neuen Domäne noch hinzufügen. Anschließend ziehst du die Daten von den Platten auf den neuen Server. OK, klingt vernünftig. Es führen halt mehrere Wege ans Ziel.

Könnte man zwar Franky-Boy, jedoch ist das in diesem Fall nicht notwendig da der OP geschrieben hatte: Demzufolge ist es völlig ok wenn sich alle FSMO-Rollen auf einem DC befinden.

Wenn die Platten an einem Controller hingen, baue die Platten samt RAID-Controller in die neue Maschine ein. So könntest du evtl. mit einer anschließenden Reparaturinstallation die Maschine wieder zum laufen bringen. Oder du installierst auf der neuen Maschine eine neue Domäne, erstellst die Benutzer und fügst alle Clients zur neuen Domäne hinzu. Ist natürlich die aufwändigste Variante.

Dann hingen die Platten wahrscheinlich an einem RAID-Contoller? Ich würde die Platten in einen laufenden Server hängen, die Daten runterziehen und alles andere dann noch auf dem neuen Server einrichten bzw. installieren.

So, nun ist es offiziell. MSDN und Technet Abonnenten können bereits am 30.04.2009 den Windows 7 RC herunterladen. Die Öffentlichkeit erhält den RC wie bereits angekündigt am 05.05.2009. Windows 7 Release Candidate Update - Windows 7 Team Blog - The Windows Blog

Servus, läuft denn der Server wieder und kannst du dich an diesem anmelden? Ja, der Systemstatus ist schon einiges Wert. Damit könntest du die Domäne wiederherstellen. Aber beschreibe erstmal was genau mit dem Server los ist. Dazu benötigen wir mehr Infos von dir. Erstmal muss der DC fehlerfrei laufen, dann sehen wir weiter.

Hier, jetzt hör uff hier "rumzuheulen". Ich habe schon einen LKW voller Tempos zu dir losgeschickt. Im Ausgleich dazu kannst du mir ja einen LKW voller Pampers zuschicken. :D Happy Weekend.

:D Ausgleich :cool: Wobei ich hoffe, dass DU mit dem "Du" nicht mich meinst. ;) :p

Bist du ruhig. Wo kommen wir denn hin wenn das jeder einfach so machen würde? Dann kommen viele noch auf "dumme Gedanken" und fummeln danach mit ADSIEdit hier und da rum. ;)

Servus, der Artikel hat doch schon eine dicke Staubschicht. ;)

Freut mich zu hören. Was war das denn für ein Problem genau? Man wächst mit seinen Aufgaben. ;)

Huhuu, du kennst doch unseren Mark, er meint das nicht wirklich so. Er schrieb ja auch "aus aktuellem Anlass". Er war bestimmt noch in Rage als er das geschrieben hat, was man in solch einer Situation natürlich nicht tun sollte und dafür erstmal tief Luft holen sollte. ;)

Servus, wenn es sich z.B. um ein Benuterkonto handeln würde, könntest du in den erweiterten Sicherheitseinstellungen des Objekts, sprich im security descriptor, im Reiter "Besitzer" den Besitzer und somit den Ersteller des Objekts herausfinden. Den Reiter "Sicherheit" im Benutzerobjekt siehst du erst, wenn unter Ansicht die Option "Erweiterte Funktionen" aktiviert wurde. Wenn das Objekt vom "Administrator" erstellt wurde, steht dort natürlich der Admin drin. Wenn jedoch jemand mit "delegierten Berechtigungen" das Objekt erstellt hat, steht dort derjenige drin.

Servus, ergänzend: Welche sich auf jedem Windows Server 2003 (Mitgliedsserver und DC) im Verzeichnis %windir%\system32 oder auf der Server CD im Verzeichnis Support\Tools befinden oder auch heruntergeladen werden können: Download details: Windows Server 2003 SP1 Administration Tools Pack Download details: Windows Server 2003 Service Pack 2 Administration Tools Pack for x86 editions Es sollte stets das Adminpak passend zum SP-Stand installiert werden.

Servus, wenn es ein Windows Server 2008 DC sein sollte, kannst du es auch recht einfach über die GUI lösen. Siehe: Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Servus, es wird nicht empfohlen einen Exchange-Server auf einem DC zu installieren, wobei diese Konstellation technisch funktioniert und auch supportet wird. Jedoch hast du bei einem Server-Crash "doppelten" Stress, da du dich um den DC und dazu noch um Exchange kümmern musst. Daher ist es empfehlenswert den Exchange auf einer anderen Maschine zu installieren. Wie bereits geschrieben, "kann" schon aber empfohlen wird es nicht.

Doch Norbert, dass finde ich schon. Denn der TO schrieb: Also könnte es sich um einen "normalsterblichen" handeln, der sich nur an einem Client anmelden soll. Naja, imho das kommt auf die Situation und die Anzahl an. Das wäre auch eine Möglichkeit. :)

Servus, du könntest es z.B. über die Eigenschaften des Benutzerkontos regeln, an welchen Clients sich der Benutzer anmelden darf. Yusufs Directory Blog - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Immer locker bleiben. Du weißt wo du uns findest. ;) Viel Erfolg.

Wenn diese aufgrund eigener Kennwortrichtlinien erstellt wurden, dann ist das korrekt. Das kommt eben auf die Anforderung an und kann durchaus berechtigt sein, eine eigene Domäne zu erstellen damit "andere" Kennwortlichtlinien genutzt werden können. So stimmt das nicht. Wenn es die Anforderung gibt, dann wird mit Bordmitteln entweder eine weitere Domäne erstellt oder was eher eintritt, dass auf Dirtt-Anbieter Software ausgewiechen wird. Möglich Anbieter könnten sein: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Gruppenrichtlinien - Übersicht, FAQ und Tutorials Jaja... das macht Microsoft immer so. Sie lassen den Herstellern bis zum nächsten Release einen "kleinen" Vorsprung, ehe sie eine Funktion selbst einbauen. ;) Büdde.

Servus, auch wenn dieser Thread bereits uralt ist, nur um das noch etwas zu ergänzen. Das stimmt, dass konnte CSVDE noch nie. Besser wäre es z.B. LDIFDE zu nutzen, denn damit lassen sich die Kennwörter aber nur bei einer SSL-Verbindung setzen. Siehe: How to set a user's password with Ldifde Weitere Optionen sind: - DSADD - Net User - VBSkript

Bonjour, jein, denn das sind keine Richtlinien sondern Passwort-Objekte und diese heißen "Password Settings Objects" (kurz PSO). Mehrere Kennwortrichtlinien mit Server 2008 - PSOs (Password Settings Object) Genau, denn Kennwortrichtlinien wirken sich auf Domänen-Benutzer nur auf Domänenebene aus. Bis einschließlich Windows Server 2003 musste deshalb eine neue Domäne erstellt werden, wenn mit Bordmitteln andere Kennwortrichtlinen erstellt werden sollten. Bis Windows Server 2003 musste man ansonsten auf Dritt-Anbieter ausweichen, was mit Windows Server 2008 und den PSOs nicht mehr notwendig ist.

Servus Pälzer, da ab Windows 2000 jeder Client standardmäßig alle 30 Tage sein Computerkontokennwort ändert, kannst du genau an dieser Stelle ansetzen. Du erstellst z.B. eine Abfrage und ermittelst, welche Clients ihr Kennwort > größer 30 Tage nicht geändert haben. Lies dir den unteren Teil des folgenden Artikels durch: Yusufs Directory Blog - Computerkonto löschen Natürlich sollte der angegebene Zeitraum so gewählt werden das wie in deinem Fall, Laptop-Benutzer oder Baustellen-Rechner die eine längere Zeit sich nicht an der Domäne angemeldet haben, berücksichtigt werden.

Servus, du müsstest alle Daten sowie Dienste vom alten DC auf den neuen "verschieben". Was das alles sein kann, erfährst du aus diesem Link: Yusufs Directory Blog - Den einzigen Domänencontroller austauschen Deine Forward Lookup Zone sollte sich ohnehin im AD befinden, denn dann regelt die AD-Replikation für dich den Rest. Ja das ist richtig, die FSMO-Rollen werden automatisch beim Herunterstufen des Rolleninhabers auf einen anderen DC verschoben. Doch ich rate immer dazu diesen Vorgang trotzdem händisch vorzunehmen, denn dann bist du dir diesen Schritt bewußt und weißt genau, auf welchen DC die Rollen übertragen wurden. Yusufs Directory Blog - Die FSMO-Rollen mit DCPROMO verschieben Wenn möglich sollten sich in jeder Domäne mindestens zwei DCs wegen der Ausfallsicherheit befinden.

Sorry Iceman, aber wenn deine Signatur stimmt "MCSE 2003", dürftest du deine Frage erst garnicht stellen. Denn wie sich das mit der DHCP-Lease verhält, hat Frank (frr) bereits korrekt beantwortet.