Daim

Servus, KEIN Benutzer - auch nicht die IT-Mitarbeiter - darf und sollte permanent mit Domänen-Admin Rechten angemeldet sein. Nur wenn administrative Arbeiten durchzuführen sind, sollte man sich mit solch einem Konto anmelden oder die Funktion "Ausführen als" nutzen. Du hast doch im AD die Möglichkeit, Aufgaben im AD den entsprechenden Mitarbeitern zu delegieren. Dieses solltest du nutzen. Dem Domänen-Admin gibst du ein kryptisches und langes Kennwort. Entwerfe und implementiere ein für euch zugeschnittenes Delegierungs- und Rollenkonzept. Dabei ist der folgende Link (samt weiterführenden) hilfreich. Yusufs Directory Blog - Objektdelegierungen einrichten Edit// So gehört sich das Jungs, zusammen sind wir stark. ;)

Ich hätte eher den Teufel verklagt und nicht den lieben Gott. ;)

Setz ein Kennwort bei den Benutzerkonten und stelle sicher, dass die Konten nicht deaktiviert sind. Bei einer autoritativen Wiederherstellung würdest du alle Informationen wiederherstellen und müsstest nichts händisch nachpflegen. Ohhaa... das musst doch wissen. Denn eine Systemstatusssicherung erfolgt doch nicht von alleine. Man erstellt regelmäßig eine System State-Sicherung entweder mit NTBACKUP oder mit einer Dritt-Anbieter Sicherungssoftware (BackupExec, ARCServe usw.).

So ist es, wobei das nichts mit dem Tool zu tun hat. Wenn ein Objekt gelöscht wird, werden eben direkt die meisten Informationen (Attribute) direkt vom Objekt gelöscht. Nur einige wenige bleiben im Tombstone erhalten, wie z.B. die Object-GUID sowie die Object-SID. Beim wiederbeleben eines Benutzerobjekts z.B., musst du die restlichen Informationen erneut (händisch) eintragen. Falls du eine Sicherung vom System State hast, kannst du auch die Objekte durch einen authority Restore wiederherstellen. Das musst du wissen. Wiederbelebe doch zuerst das Tombstone, dann kannst du immer noch entscheiden, ob dir das reicht und du noch die fehlenden Informationen händisch einpflegst oder ob ein autoritativer Restore das richtige ist. Aber dazu muss eben eine Systemstatussicherung existieren.

Den gibt es zwar auch, aber mein Nick kommt nicht davon, sondern aus der Graffiti-Szene (Old School ;) ). Genau so ist es.

Servus, dann lade dir das ADRESTORE.NET herunter und wiederbelebe die Tombstones. ADRestore.NET rewrite - Windowmaker's blog Yusufs Directory Blog - Active Directory Wiederherstellung

Grizzly meint die hier: ;) How to detect and recover from a USN rollback in Windows Server 2003 How to detect and recover from a USN rollback in Windows Server 2003

Wobei es aber immer noch nicht ganz klar ist, ob es sich hierbei tatsächlich um einen SBS handelt. Bisher hat der OP lediglich einen Link der zwar für einen SBS gedacht ist gepostet, aber die Vorgehensweise in dem KB-Artikel zum Überprüfen der AD-DB wie auf jedem anderen (normalen) DC identisch ist. Das ändert aber natürlich nichts an der Tatsache, dass hier der DC neu aufgesetzt werden muss.

Hola, guckst du hier: http://www.mcseboard.de/windows-forum-ms-backoffice-31/zeit-falschen-dc-syncronisiert-141173.html#post866755

Ach was... ACRONIS wirds schon (ve)r(n)ichten. ;) SCNR.

Das wird schwierig, denn um das zurücksetzen des Kennworts für den DSRM muss der entsprechende DC natürlich online und erreichbar sein. Die Vorgehensweise wäre dann wie folgt: 1. Auf einem anderen DC gehst du auf START-AUSFÜHREN und rufst NTDSUTIL auf. 2. Danach gibst du diesen Befehl ein: set dsrm password 3. Als nächstes folgt dieser Befehl: reset password on server <FQDN-des DCs> 4. Mit "q" (zweimal) verlässt du NTDSUTIL.

Unschön. Existieren noch weitere DCs (lass mich raten, nein)? Eieieii... du hast nicht zurückgesichert, sondern zurückgeimaget. Ein kleiner aber feiner (und wesentlicher) Unterschied. Wie ich dieses Thema Imaging liebe... :rolleyes: Nicht gut. Wenn du das Kennwort vom DSRM (Directory Services Restore Mode) resetten möchtest, was du im Übrigen nur online durchführen kannst, dass Kennwort also nicht kennst, wie um Himmels Willen konntest du dich dann anmelden? Du sprichst weiterhin für mich in Rätseln. :(

Servus, die Gruppenmitgliedschaften werden nur bei der Anmeldung eines Benutzers ausgewertet. Die Änderungen der Gruppenmitgliedschaften wirken sich nicht online aus. Denn das Access Token wird nur einmal bei der Anmeldung erzeugt und wird während der laufenden Benutzersession nicht automatisch aktualisiert. Der Benutzer muss sich neu anmelden.

Hola, immer locker bleiben (im Ernst). Ein Exchange auf einem DC wird z.B. auch aus genau deinem Problem heraus, seitens Microsoft nicht empfohlen. Es wird aber supportet. Welche Datenbank? Die AD (NTDS.dit)? Und was bitte bedeutet "verabschiedet"? Macht die DB gerade eine Rundreise oder wie? :p Welches Backup? Das System State? Das ist natürlich mehr als ungünstig. Welche Fehlermeldung erhälst du beim zurücksetzen des DSRM-Kennworts? Unter Windows Server 2003 lautet der Befehl: set dsrm password How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003 Oder mit SETPWD: How to Change the Recovery Console Administrator Password on a Domain Controller Wieso muss erst das AD repariert werden? Wenn du eine System State Sicherung rücksicherst, muss anschließend nichts noch zusätzlich repariert werden. Für was sichert man dann die Sicherung zurück? Erläutere bitte detaillierter deine Situation.

Wenn du mehrere DCs in der Domäne hast, musst du natürlich auf allen DCs das Eventlog kontrollieren. Ansonsten erstelle dir doch einen Test-User und lösche diesen. Anschließend kontrollierst du das Eventlog erneut und wirst danach schnell merken, dass es die EventID 630 ist.

Servus, ja, standardmäßig wird es. Dann schau genauer hin. Schau in das Sicherheitsprotokoll der DCs und suche nach der EventID 630. Denn standardmäßig wird das löschen eines Benutzerkontos nämlich protokolliert.

Ich bin auch dabei. Egal wer reserviert, die Reservierung sollte auf den Namen "MCSEboard" lauten. Ich bin noch an einem Überraschungsgast dran, dass kristalisiert sich aber erst am Freitag raus.

Bonjour, dieses Szenario wird seitens Microsoft nicht supportet, da Vista sowie Windows Server 2008 in einer NT-Domäne nicht mehr berücksichtigt wird und somit auch nicht getestet wurde. Es kann bei dem Vorgang aber auch zu Problemen mit dem NTLM kommen. Die alte Version ist auf dem Windows Server 2008 deaktiviert. Des Weiteren kann es auch sein, dass du vorher das Computerkonto in der NT-Domäne erstellen musst. Siehe: Error message when you try to join a Windows Vista-based client computer to a Windows NT 4.0 domain: "Logon failure: unknown user name or bad password"

Huhuu (ohh, eine Anrede mit Namen, erlebt man auch selten bzw. wenn, dann wirds spannend. ;) ) Stimme ich völlig zu. Hmm.. naja, schon. Vor der Implementierung eines neuen Designs, lohnt sich solch eine Simulation auf alle Fälle. Wenn diese aber nicht gemacht wurde und das Unternehmen startet eben einfach aus dem Bauch heraus mit zwei DCs und bekommt im laufenden Betrieb Probleme, ist solch eine Simulation mit dem Tool sicher nicht verkehrt. Sehe es als zusätzliches Mittel und um weitere Erkenntnisse zu gewinnen an. Wir sind uns ja einig, eine Langzeitaufzeichnung bringt die besseren und aufschlussreicheren Werte, ohne jeden Zweifel. Es gibt keine. :) Klar, dass wäre kein echter Test. So etwas muss natürlich vor dem Live-Betrieb durchgeführt werden. Der vollständigkeitshalber. Wobei ich zugeben muss, dass Tool kam zu Beginn von Windows 2000 raus, als noch keine tiefergehenden Informationen und Erfahrungen bzgl. des Verhalten des AD vorlag. Achwo... wir sind noch On-Topic. :)

Richtig. Genau. Mit ADTest kann man auch z.B. die Benutzeranmeldung sowie Suchanfragen simulieren. Daher ist imho das Tool nicht verkehrt. Das war auch nicht als Empfehlung gedacht.

Klar musste die Frage kommen, denn die Umgebung spielt doch als einer der wichtigsten Rollen. OK. Dann hast du die falschen Suchwörter verwendet. ;) Eine Art Stress-Tool wäre z.B. ADTest: Download details: Active Directory Performance Testing Tool (ADTest.exe) Zu Windws 2000 Zeiten veröffentlichte Microsoft auch ein AD-Sizer Tool: Download details: Active Directory Sizer

Servus, also die Mindestanzahl an DCs habt ihr ja schon mit zwei DCs. Neben der Anzahl an Objekten, kommt es aber auch auf die Struktur der Umgebung an. Wieviele Standorte existieren, in welchen Ländern, mit welcher (stabilen) Bandbreite, existiert Exchange, existieren Applikationen die vom AD abhängig sind, wieviel Last besteht auf den DCs während den Benutzerauthentifizierungen? Alle diese Faktoren spielen bei der Anzahl der DCs innerhalb einer Domäne eine Rolle. Aber jede Domäne sollte (um nicht zu sagen "müsste") zwei DCs haben, damit eben bei einem DC-Crash die Domäne noch weiterhin besteht. Das schließt natürlich nicht eine regelmäßige SYSTEM STATE-Sicherung aus. Die muss ohnehin durchgeführt werden. Ansonsten siehe: Determining the Minimum Number of Domain Controllers Required: Active Directory Step B2: Determine the Number of Domain Controllers

Doch, die Rollen können verschoben werden. Wenn aber dann der SBS nicht abgeschaltet wird, wandelt er sich zum Fahrstuhl-SBS. ;)

Hello, du kannst auch die Daten mit NTBACKUP sichern und auf der neuen Maschine erneut rücksichern. Mit XCOPY /O geht das auch. Die Freigaben kannst du vom "alten" Fileserver aus der Registry exportieren und auf der neuen Maschine importieren. Start - Ausführen - Regedit - HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares Nach dem importieren ist anschließend der Serverdienst neu zu starten.

Servus, dieses hier kann ich dir nur ans Herz legen: Exchange Server 2007 - Der schnelle Einsieg: Marc Jochems, Walter Steinsdorfer Es ist praxisnah geschrieben.