Daim

Servus, auf dem neuen DC hast du auch das DNS installiert, wobei sich deine Forward Lookup Zone im Active Directory befinden sollte (AD-integriert gespeichert). Zusätzlich sollte der neue DC auch GC sein. Falls das der allererste DC sein sollte, sichere noch das EFS-Zertifikat. Verschiebe dann die FSMO-Rollen auf einen 2003er DC und achte darauf, dass alle DCs auch GC sind. Die haben mit diesem Vorgang nichts zu tun, es sei denn, die Dateien liegen auf dem 2000er DC. Dann müssen diese natürlich auf einen bestehenden Server verschoben werden. Nope, da gehts nichts schief. der DC wird zum Memberserver natürlich nur, wenn es nicht der allerletzte DC einer Domäne ist ;) . Was soll dann, da noch schief gehen :p .

Klar findest du es mit ADSIEdit nicht, denn es steckt ja auch im "versteckten" Container Deleted Objects. Dazu brauchst du z.B. den LDAP-Browser LDP.exe aus den Windows Support Tools. Das bekommst du am besten raus. Was wurde in letzter Zeit gelöscht, das Computerkonto, der Drucker ? Wenn das Computerkonto im existiert und auch angezeigt wird, dann liegt es nicht daran. Es liegt an einem Objekt, dass bereits belöscht wurde und erst endgültig aus dem AD entfernt wird, wenn die Tombstone Lifetime abgelaufen ist.

Das sagst du aber jetzt hoffentlich nicht zu mir, oder ? Den Artikel auf den ich verlinke, habe ich selbst geschrieben und erwähne deinen Einwand direkt im ersten Satz. Und um auf deinen Einwand zu antworten: Wann bitte schön - wenn nicht bei einem DC-Crash - wäre es denn empfohlen eine ASR-Sicherung einzuspielen ? Was vor einem rücksichern einer ASR-Sicherung alles versucht werden sollte, wird im Artikel dann im zweiten Satz erwähnt.

Hmm... ich würde sagen, "zu kurz gesprungen" ;) . Dann wäre der Fehler 1988 das "kleinste" Übel, denn dann wäre im Eventlog "Karneval in Rio". Der Fehler 1988 würde dann erst garnicht protokolliert werden. Dieser besagt ja, dass ein Objekt/Attribut nicht repliziert werden konnte, der Rest aber schon.

Aloha, nie und nimmer. Das musst du genauer erläutern. Evtl. war es ein Ansichtsproblem, aber durch das installieren von Winzip (wozu eigentlich?) zerschießt sich nicht das AD. Wen ? Deshalb kann deine Interpretation nicht stimmen. Wenn das AD zerschossen ist und du es neu installieren musstest, dann hätte er nichts erkannt. Ich fürchte, dein vorheriges Problem war eher ein kleines, aber jetzt... Das wundert mich nicht :rolleyes: . Lass mich raten; Es ist dein einzigster DC. Du könntest auf einer anderen Maschine eine neue Doämne erstellen und anschließend mit ADMT die Benutzer- sowie Computerkonten in die neue Domäne migrieren. Der Vorteil an ADMT ist, es bleiben dir alle Einstellungen bezgl. der Profile erhalten. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Was ich aber vorher versuchen würde, auf einer anderen Maschine den Server zu installieren und diesen dann als "zusätzlich DC" in deine bestehende Domäne hinzufügen. Evtl. wenn du Glück hast, besteht lediglich ein lokales Problem und es liegt nicht am AD. Wenn sich dann die DCs repliziert haben, kannst du den ersten DC neu installieren. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Klar, der Übeltäter liegt in der Domänenpartition "domain.local". Du musst das Eventlog genauestens auswerten und beachte meinen Artikel im vorherigen Post.

Servus, diese Frage kann man sich sparen, wenn man weiß, für was der Fehler 1988 steht ;) . @Hwimmer Der Fehler 1988 entsteht, wenn mindestens ein DC mit mindestens einer Verzeichnispartition, sich nicht während der Tombstone Lifetime replizieren konnte. Den genauen Vorgang kannst du hier nachlesen und auch, was die einzelnen Schritte dazu wären: Yusuf`s Directory - Blog - Lingering Objects (veraltete Objekte) In der Fehlerbeschreibung des Fehlers 1988 stehen normalerweise auch Hinweise um welche Objekte es sich handelt, die man dann mit ADSIEdit löschen könnte. Kontrolliere weiterhin auch die anderen DCs, was im Eventlog dort protokolliert wird. Die entscheidende Frage die du dir dann beantworten musst, wäre: Wie konnte das passieren ?

Serus, für einen DC, würde ich die ASR-Sicherung empfehlen. Die regelmäßige System State Sicherung mit dem Betriebssystemeigenen Sicherungsprogramm NTBACKUP, sollte weiterhin durchgeführt werden. Bei einem DC-Crash bräuchte man bei bestehender ASR-Sicherung, lediglich den Server neu zu installieren (falls eine Neuinstallation nötig wäre), der Computername bzw. die IP-Informationen wären egal, denn bei der ASR Sicherung wird das System State mit gesichert, worin die Registry ein Teil davon ist. Da in dre Registry genau diese Informationen (Name, IP etc.) sind die Daten nach der Rücksicherung des ASR zum Stand der ASR-Sicherung erneut hergestellt. Automatische Systemwiederherstellung (ASR) - faq-o-matic.net

Servus, ... und wo wird der Account für den Modus "Verzeichnisdienste wiederherstellen" gespeichert ? ;) .

Hehe... das verwechselst du aber jetzt. Ich meine nicht das Benutzerkonto-Kennwort, sondern das Computerkonto-Kennwort das sich standardmäßig alle 30 Tage erneuert. Lies nochmals den Link und auch die dort verlinkten Artikel ;) .

Nichts leichteres als das ;) . Stichwort: Computerkonto-Kennwort. Yusuf`s Directory - Blog - Computerkonto löschen

Servus, aktiviere im Snap-In "Active Directory-Benutzer und -Computer" die "Erweiterte Funktionen" unter dem Menü-Punkt Ansicht. Danach wählst du die Eigenschaften des Containers bzw. der OU, in dem der Benutzer in die Rechte delegiert wurden. Im darauffolgenden Fenster wechselst du in den Reiter Sicherheit. Dort markierst du den Benutzer und wählst unten die Option Erweitert aus. Im darauf erscheinenden Fenster, kannst du im Reiter Berechtigungen die Rechte die der Benutzer hat, einsehen.

Servus, ja, die 5.000 Grenze soll zwar zu Zeiten von Windows Server 2003 behoben sein (was sie auch tatsächlich "mindestens in Bezug auf Gruppen" ist), aber für Microsoft gelten diese 5.000 als "supportet". Je mehr diese Zahl übertroffen wird, desto höher besteht die Gefahr in ein "Out-of-Version-Store" Fehler zu laufen. Die Rede unter Windows Server 2003 ist vom Linked Value Replication (LVR). Hat aber jetzt nicht direkt mit dem Problem des OP zu tun ;) .

Dann sollte sich mal der Kunde erneut durch den Kopf gehen lassen. Aber lassen wir das... Ja. Da vermutet ihr nach meiner Meinung völlig korrekt. Deshalb hatte ich auch den MS-PSS erwähnt. Denn wenn euch dazu jemand eine klare Antwort liefern kann, noch dazu bei der getätigten Schemaänderung, dann kann es nur der MS-PSS. Der Anruf liegt bei 199 Euro. Falls ihr da anruft, würden mich (und sicher einige mehr) die Infos sehr interessieren ;) .

Aloha, das ist der einzigste Artikel, der überhaupt irgendwelche Grenzen aufzeigt. Das sind bei weitem nicht alle :( .

Servus, ich kenne ähnliche Fälle (z.B. bei diversen Abfragen), bei denen ähnliche Fehlermeldungen bezgl. "Limit exceeded" erscheinen. Leider sind diese Grenzen nirgends dokumentiert und in deinem Fall denke ich, dass dir höchstens der Microsoft Produkt Support Service (MS-PSS) dazu etwas sagen kann :( . Ihr habt doch sicherlich die Schemaänderung sauber (im Sinne von Microsoft) ausgeführt. Was man vielleicht in Frage stellen könnte, ob das AD, dass richtige Werkzeug in eurem Falle ist...

Das wird nicht dein Problem lösen. Wenn die Clients den neuen DC als DNS-Server mitgeteilt bekommen, müssen die sich trotzdem authentifizieren können.

Ist das Eventlog vom neuen DC sauber ? Ein DCDIAG /v bringt keine Fehler ? Wie lautet die genaue Fehlermeldung, wenn der alte DC heruntergefahren wurde ? Der neue DC hat sich mit seinen SRV-Records im DNS eingetragen ? Wenn der alte DC unten ist, lässt sich der neue DC weiterhin mit seinem Namen anpingen ?

Servus, das entscheidende daran, wäre der GC. Die FSMO-Rollen werden für die Authentifizierung der Benutzer nicht benötigt. Wichtig ist vorallem das DNS. Daher sollte jeder DC auch das DNS installiert haben. Dieser DC/DNS muss natürlich den Clients bekannt sein, entweder statisch oder per DHCP.

Naja, man kann das (mit Aufwand) zum laufen bringen, zukunftsorientiert ist das aber nicht. Mit einem FQDN ist man auf der sicheren Seite, auch für die Zukunft. Da kann ich nur sagen, bevor ich eine produktive Domäne umbenenne, setze ich sie neu auf. Natürlich nur dann, wenn es die Umgebung zulässt. Entscheidend bei diesem Vorgang sind immer die eingesetzten Applikationen und ob diese eine Domänenumbenennung (die ohnehin nur im Modus Windows Server 2003 möglich ist) verkraften.

Servus, das riecht mir zu sehr nach einem single-label Domänenname und dieser Artikel scheint es mir zu bestätigen: Event ID 6702 occurs when you use a single-label domain name on a Windows Server 2003-based computer Das ist natürlich unschön (was soviel heißt, dass es tecnisch nicht ideal ist), eine Domäne lediglich mit einem einfachen Namen zu betreiben. Jede Domäne ab Windows 2000 sollte einen Fully Qualified Domain Name (FQDN) besitzen, der mindestens aus zwei teilen besteht, getrennt durch einen Punkt (z.B. intra.contoso.com). Wenn es sich tatsächlich um eine single-label Domäne handelt, kann dieser Artikel ebenfalls interessant sein: Informationen zur Konfiguration von Windows für Domänen mit DNS-Namen mit einfacher Bezeichnung

Servus, ich weiß zwar nicht ob ich dich richtig verstanden habe, aber ich werfe mal SUBINACL in die Runde ;) . Wie halte ich die ACLs auf meinem Fileserver sauber? - faq-o-matic.net

Servus, jein, sollten sie nicht bzw. kommt auf das Design drauf an. Die Zone _msdcs.DeineDomäne.TLD ist für die DCs der gesamten Gesamtstruktur interessant, denn dort tragen sich die DCs wichtige Einträge ein. Deshalb wird diese Zone standardmäßig im ganzen Forest repliziert. Die anderen FLZ werden jeweils in ihrer eigenen Domänen repliziert. Das kommt eben auf das DNS-Design an. Man könnte eine Zone in der ganzen Gesamtstruktur erstellen nud diese dann, wie die _msdcs... in der Gesamtstruktur replizieren lassen. P.S. Es sollte idealerweise die Einstellung "Nur sichere" Updates gewählt werden!

Servus, siehe: Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

Ahsoo, ok. Dazu kenne ich nun wiederum keinen Artikel.